缺金的男寶寶名字(木命的人起公司名字)

本篇文章給大家談?wù)勅苯鸬哪袑殞毭?，以及木命的人起公司名字的知識點，希望對各位有所幫助，不要忘了收藏本站喔。

文章詳情介紹：

• 1,《紅樓夢》賈寶玉名字點評
• 2,開源 DevOps 工具《建木》實踐

《紅樓夢》賈寶玉名字點評

賈寶玉是《紅樓夢》的主人公，性格方面溫和多情、叛逆、平等自由、軟弱怯懦、不求上進。

從姓名上看，賈、寶、玉三個字五行都屬于金，這種金與鋼鐵之類的金不同，為陰性之金，八卦上歸兌卦。

賈寶玉為男性，名字卻是純陰之金，先天便缺少陽剛之氣，為女人之象，因此舉止行為上表現(xiàn)出愿意和女人相處在一起。《紅樓夢》原文中賈寶玉曾說：女兒是水做的骨肉，男人是泥做的骨肉。我見了女兒，我便清爽；見了男子，便覺濁臭逼人。

賈寶玉為兌卦，兌卦上面為陰爻，下面兩個陽爻，上有缺損。最上方可代表人的頭部，頭部有缺，會表現(xiàn)出神經(jīng)質(zhì)的特點，人的行為舉止有時瘋瘋癲癲，這也是賈寶玉在《紅樓夢》中的日常表現(xiàn)之一。

兌卦為少女為柔順，賈寶玉性格上軟弱怯懦在情理之中。

純陰性的名字與純陽名字在五行上都是能量相對集中，具有人格魅力，因此賈寶玉才能得到眾多女子的青睞。

兌卦還具有欲望強烈之特性，這與賈寶玉在《紅樓夢》中處處留情也完全符合。

開源 DevOps 工具《建木》實踐

一. 建木介紹

1.建木簡介

第一次聽說”建木“是建木的一個發(fā)起人談到，這名字聽著感覺有新意，但當時不甚了解，后來查了相關(guān)資料，才有所認識。摘錄官網(wǎng)一條介紹：

“建木”是上古先民崇拜的一種圣樹，傳說建木是溝通天地人神的橋梁。伏羲、黃帝等眾帝都是通過這一神圣的梯子上下往來于人間天庭?！痘茨献印椥斡?xùn)》亦曰 ：“建木在都廣，眾帝所自上下。日中無景，呼而無響，蓋天地之中也?！?/p>

DevOps 是從需求到研發(fā)、到落地的一種自動化和平臺設(shè)計的一種理念，是溝通過程中各個階段的橋梁，作為 DevOps 落地工具的”建木“，取之其名甚妙也。

2.初試建木

知道建木這個 DevOps 工具后，決定在實際項目中試一試，翻了一遍建木的文檔，把建木給安裝上了，開始使用。

開始使用時，低代碼的配置方式，讓 ”Hello world“ 起來非常方便。但要更進一步的時候，卻感覺無從下手了，對比自己熟悉的 Jenkins 來，時間緊張的項目工期還是迫使自己放棄進一步嘗試。

于是雖然一直在建木社區(qū)群里，只是長期潛水。

3.再試建木

雖然沒有在項目落地建木，但也對建木持續(xù)關(guān)注著，看著出品方一個個版本的發(fā)布，感覺功能越來越強大了、也更加有吸引力了，總想著什么時候再來一探究竟。

近期公司要上一新項目，DevOps 工具首選自然還是 Jenkins，但想到 Jenkins 配置的繁瑣，心里嘀咕著，決定試一下建木，看看這個傳說中北半球第二好用的 DevOps 工具，到底能給工作帶來怎樣的體驗。

于是，開始進一步的實踐嘗試。

二. 建木實踐

1.建木的安裝

建木的安裝極其方便，官方提供 Docker 鏡像，支持 docker-compose 和 kubernetes 部署，一鍵完成。

2.開始使用

建木的界面非常簡潔，運行的插件采用了 Docker 化的底層支持，省掉了一堆麻煩的插件安裝和配置的過程。

下面就用建木最新版本 v2.6.2 本地化部署，以一個簡單的 maven 構(gòu)建過程作為演示流程，介紹一下建木的入門級使用。

01

主界面

非常簡潔的主界面。

02

密鑰管理

配置流程前，可以將一些常用的變量、密鑰配置到”密鑰管理“中，建木除了默認的密鑰存儲方式外，也支持對接 vault 進行存儲，安全性有了進一步的保障。

配置界面如下：

03

流程配置

點擊主界面的”圖形項目“圖標，進入流程配置界面。

頁面左邊為執(zhí)行節(jié)點，官方提供了比較豐富的節(jié)點庫，社區(qū)也有大量有心人士提供的節(jié)點。

選擇 ”git clone“ 節(jié)點，拖拽到頁面中間的配置區(qū)，點擊節(jié)點圖標，頁面右側(cè)出現(xiàn)該節(jié)點的配置項，按需要填寫節(jié)點配置信息。

再增加一個 "maven構(gòu)建" 節(jié)點，在兩個節(jié)點間建立連接，選擇節(jié)點相關(guān)的 JDK 版本后，再配置相關(guān)參數(shù)，保存后返回。

一個流程就這樣創(chuàng)建完成了。

上面的流程，可以用 DSL 語法實現(xiàn)同樣的配置：

name: workflow測試 description: "" global: concurrent: false pipeline: node_0: alias: git clone type: _/git_clone:1.2.5 param: username: ((tisvc_key.git_username)) password: ((tisvc_key.git_password)) remote_url: http://gitlab.tyun.cn/tyun/tiops-agent.git ref: refs/heads/master commit_id: "" depth: 1 node_1: alias: maven構(gòu)建 type: _/maven_build:1.3.1-jdk11 param: workspace: ${node_0.git_path}/src mvn_action: package extra_arge: "" nexus_username: admin nexus_password: "123456" maven_public_id: public maven_public_url: https://maven.aliyun.com/repository/public maven_release_id: release maven_release_url: "" maven_snapshot_id: snapshot maven_snapshot_url: "" docker_username: jianmudev docker_password: "123456" image_name: imagename image_tag: latest vc_pom_dir: .

04

流程執(zhí)行

在主界面點擊流程的”觸發(fā)“按鈕，觸發(fā)流程執(zhí)行，進入流程執(zhí)行信息界面后，可以查看每個節(jié)點執(zhí)行的輸出日志。

這樣，一個簡單的流程采用了更加簡單的配置過程，就這么簡單地實現(xiàn)了。

在建木中，除了采用圖形項目的方式外，也可采用代碼項目的方式，使用 DSL 描述語法，來創(chuàng)建 DevOps 流程，除了創(chuàng)建的方法不同外，執(zhí)行的邏輯是完全相同的。

三. 深入探索

1.遇到一個問題

在當前項目實際使用中，因目前處于開發(fā)階段，對于 DevOps 流程來說，模塊的拆分及更新，希望流程也能拆分來實施。

建木 Docker 化的節(jié)點運行方式，是其優(yōu)點，也是其有些不適應(yīng)的地方，就從上面演示流程中的 "git clone" 和 "maven 構(gòu)建" 節(jié)點來說：

01

“git clone” 節(jié)點本地存儲采用的是 Docker 臨時創(chuàng)建的目錄，該目錄在同一條流水線中可以共享，但流程結(jié)束后該目錄也會被清理，在多模塊拆分流程的情況下，每一次執(zhí)行都需要全部重新 clone；

02

“maven構(gòu)建” 節(jié)點每一次構(gòu)建后的中間文件和結(jié)果文件，隨著流程的結(jié)束消失了，這樣每次構(gòu)建都需要從頭構(gòu)建；

03

“maven構(gòu)建” 本地緩存目錄設(shè)置在 Docker 中，節(jié)點運行結(jié)束后容器也就結(jié)束，每一次構(gòu)建都需要從 maven 遠程倉庫重新拉取依賴包。

上面的問題，在頻繁執(zhí)行流程的時候，不好的感覺就會被放大。于是去社區(qū)尋求答案，但在開源社區(qū)看到技術(shù)團隊有明確表示對類似問題暫時不考慮，從官方尋求支持就比較困難了。

2.如何解決

在使用的過程中，發(fā)現(xiàn)如果要實現(xiàn)持久化共享目錄的話，有一個方法是采用 “SSH執(zhí)行命令” 節(jié)點，但這樣所有的流程都轉(zhuǎn)化為 shell 腳本問題，顯然不是好的解決方案，也無法體現(xiàn)建木在流程方面的優(yōu)勢了。

從 gitee 拉取了建木的源碼，分析建木的幾個模塊后，確認流程的執(zhí)行主要是由三個模塊完成：jianmu-ci-server、jianmu-worker-docker、runner節(jié)點，那實現(xiàn)目錄共享可以從這三個模塊入手。于是計劃在 DSL 描述語法的 spec 區(qū)域，增加一個對 runner 節(jié)點 VolumeMount 的支持。

動手修改了 jianmu-ci-server、jianmu-worker-docker的代碼，在發(fā)布測試 runner 節(jié)點的時候，沒有通過 DSL 語法的校驗，嘗試失敗，此路不通。

上面的路走不通了，但是路還是要走的， 最終決定用比較直接的方法，修改 jianmu-worker-docker 模塊，為 runner 節(jié)點增加一條 /workspace:/workspace 的目錄映射，代碼如下：

// 掛載 /workspace 目錄，以存放希望在流程中持久化的文件 config.Mounts = append(config.Mounts, mount.Mount{ Type: mount.TypeBind, Target: "/workspace", Source: "/workspace", })

這樣每一個 runner 節(jié)點都能有一個本地主機的目錄映射，達到了目錄共享持久化的目的，至于具體 runner節(jié)點 的使用，則由 runner 節(jié)點自行支持了。

針對上面遇到的問題，在官方的 “git clone” 和 “maven構(gòu)建” runner 節(jié)點的基礎(chǔ)上，添加了兩個自定義節(jié)點，增加了對 /workspace 目錄的使用。

四. 小結(jié)

通過在項目中對建木的使用，感覺建木在設(shè)計上是非常符合 DevOps 理念的，并且通過簡單的配置或者簡潔的 DSL 語法，就可以滿足工作中的流程需求，相較于 Jenkins 的使用，非常便利，適合上手、適合上頭。

但目前建木還處于成長期，有些功能還不是很完善，希望技術(shù)團隊能繼續(xù)努力，為 DevOps 領(lǐng)域帶來功能更加強大、使用更加便捷的落地工具。