Re: [請益] 使用自動化組態設定工具的經驗

[qrtt1 (有些事，有時候。。。)]

※ 引述《dream1124 (全新開始)》之銘言：
: ※ 引述《qrtt1 (有些事，有時候。。。)》之銘言：
:  謝啦~ q大 你又幫我上了一課
: :         偏好 Ruby 的由 Chef, Puppet 下手
: :         偏好 Python 的由 Ansible, Salt 下手。
: :         (至少在選擇困難的議題上，你已省力了 50%)
:  難怪不常聽到 java 社群的人提這些工具，呵呵

        單純以實作專案需求為主的工程師，

        比較少會關注與 server side 管理的相關工具

        這跟特定語言的關係比較沒那麼大

        反而跟公司或團隊的規模 對於 技術採用 的範圍比較有關

        因為我最初的工作是在 startup 團隊裡打工

        本來只有純寫 java web，後來漸漸摸到一點前端

        再後來也得管理 server，並參與移機作業才會摸得到這些



        至於現在在公司也有參與到 Ops 的流程

        現況的心得大致像

        《一個人的 Ops》
        http://bit.ly/1N4v3ks


: :         依據過去你在版上的討論，加上文末提到的 Java。
: :         我猜測是要部署 Java Web Application 為主，
: :         有點難理解這類的應用程式為何會難部署，
: :         你可能得再補充實際上的『痛點』才能讓有解的人給予建議
: :         舉例來說：
: :         純 Servlet Container 像 Tomcat 有 RESTful API 能更新
: :         較大一點的 Application Server 像 Weblogic 有 WLST 介面
: :         能用 jython 或 ANT 來更新程式、變更設定...

        應該只是碰巧，

        公司本來是用 Weblogic，但實在沒用到 Application Server 的功能

        隨著 License 的時間到期，只好力推轉純至單純的 Tomcat。

        反正 Tomcat 單純 update context 時會 keep session 已經算很方便的了

        除了沒有好看的、內建 monitor dashboard，實在沒什麼好挑剔


    PS. 反正現在是流行把 Log 或 Metric 導出來接 ELK stack，

        單一軟體的 Dashboard 也沒那麼重要了


:  其實主要希望只用少數幾樣工具就能部署各類程式到許多作業系統，

        在我看來『許多作業系統』的目標有點太大而難以達成，

        即使同樣是 linux，就有點懶得去搞定 ubuntu, centos 微妙的不同

        或者 同是 ubuntu、同是 centos 在改用 systemd 前後的不同，

        更不用說要去弄 linux, osx, windows 都符合的情況。



        另外，我注意到我們著重的情境比較不同，得先把它區分清楚

        免得讓討論的焦點互相悖離太多



        我先前與目前的回復，較著重在實際『部署』的 product server。

        據前一篇文章與這篇的資訊，你有疑問有 2 個重心：

        1. 應用程式部署

        2. 開發環境建置

        要找一套工具同時服務二種不同導向的需求，

        實在是太困難了，若是針對開發環境，比起薪資水準多少

        談硬體需求反而比較實際，

        像我現在是用 mbp 2011 early 擴充到 16 GB RAM，

        要開多個 vagrant box 作為不同專案的開發環境挺方便的



    PS. 若針對『多種作業系統』以 Windows 為主的話，

        先前知道的訊息是 Puppet 較優

      （但這是我腦中沒機會再更新過的訊息，若有需要得再自行研究了）





:  要是這工具還能夠實現你提到的 infrastructure as code 那就更好。
:  也就是說....我想盡可能採用統一的方法部署程式。

        infrastructure as code 是目標 (以下簡稱 IaC)，

        除了 Data Server (各種 DB 是需要人工細心照料)，

        靠 configuration management tool（以下簡稱 CM）

        只是能滿足大部分『常見』情境

        也就是那些工具被創造出來時，原作者與後繼貢獻者的需求集合

        與自己環境接起來的『體力活』！



        由你目前的情境到 IaC 中間的歷程應該是什麼？

        IaC 描述的是一種狀態，為了將你那些未管理、或未優化的流程

        變成可被描述的態狀。

        所有的行為必需能變成指令與『參數』

        那些還需要人工操作的部分，得找出對應的指令才有機會

        難以簡單用現成 command line 搞定的，

        用 Browser/GUI automate toolkit 也行

        如果上述都無法輕易達到，那就寫自己的工具而已


:  否則，我們還真的有 Tomcat 和 Weblogic 等環境(你是不是猜到我公司...嘿嘿)
:  若開發人員需要學習多套部署與管理方法才能動手開發，那也未免太麻煩。
:  在最近的 infrastructure as code 還沒喊得震天價響之前，
:  我就認為開發環境的建置方法應該要一致、自動、容易重建與複製。


        不用 web server 的管理，這部分跟 IaC 的關聯比較不大了，

        你可以提供一個簡單的 command 把它們的差異隱藏起來

        （只是把寫程式的多型的概念，拿出來用而已）



        至於開發環境，無論是 Tomcat 或 Weblogic 都有 Plugin 能直接使用

        以 Eclipse 來說 ，同一種 OS 更是可以直接 zip 起來，到另一台使用

        相關的檔案也都能比照辦理。




:  現在乍看 docker 是比較可行的方案....
: :         先試著回想一個問題，
: :         上一次『從無到有』建出完整的系統，所有機器是什麼時候的事了？
: :         要建出完整的系統，從一個空的 Server 安裝好 OS 後，
: :         需要多少步驟、時間才能完工呢？
: :         而這些安裝的細節是怎麼保存、怎麼與現狀同步的？
: :         在過去，我們是依賴著一代一代傳下來的交接文件，
: :         隨著 Server Admin 換人，或新專案啟動多少會影目前的配置
: :         文件能不能近可能接近與『現況』同步的狀態是相當大的挑戰
:  這是現在我傷腦筋的問題
:  配發同事電腦的部門好像經常會調整作業系統的設定與軟體配置，
:  在此同時，每個專案的環境建置方法又不一致，還會在開發過程中被調整，
:  因此建置專案環境的文件實在不容易跟現況同步。
:  請問大家方便分享一下你們各自的解決方法嗎？


        個人的環境基本上我是不參與的，

        如同先前所陳述的，我得將這段的回覆標為『部署環境』而非『開發環境』

        每個人有他最有生產力的環境，要不要統一規定則是政治與團隊風格問題



: :     PS. scale in/out 大部分是架構設計的問題，
: :         部署工具的角色主要在：
: :         1. 建出一個基礎只差修正 config 或更新部分應用程式
: :         2. 異動管理（部分程式更新或設定變更）
: :         不太有時間讓你要 scale out 時用 deploy tool 慢慢從無到有裝起來
: :         通常會包成能比較快速啟動的型式（VM 的 image）
: :         或是預先好的安裝包（例如 RPM, DEB）
: :         http://techblog.netflix.com/2016/03/how-we-build-code-at-netflix.html
:  這段資訊觸碰到問題的核心，真的很實用，謝謝！
: :         莫驚慌、莫害怕。
: :         即使他們什麼外掛都沒有，還有最終一招『呼叫外部程式』
: :         總可以呼叫他們的 command 去做事唄 :)
:  呵呵，其實這只是想盡量偷懶，我要優先評估支援範圍比較廣的工具。
: :         開發人員的行情 跟 做這些事沒有關係
: :         開發人員的行情 跟 做這些事沒有關係
: :         開發人員的行情 跟 做這些事沒有關係
: :         不管薪水多少，得要為自己謀福利。
: :         包含部署應用程式的舒適感
: :         與
: :         維護部署應用程式的應用程式的便利性
:  哈..從開發人員的角度來看，像我們這樣有信心駕馭這些東西的人當然想用好工具，
:  但如果我真的希望能導入這些工具，那就要深入探索一些問題的答案。
:  因此這個問題才會看起來比較奇怪，其實我想問的是 「根據大家的經驗，
:  實力的行情價在42k左右的開發人員能否順利使用 docker 建置開發環境」？


        我還是無法將行情與 docker 的邏輯聯接起來。

        比起薪資行情，

        要掌握 docker 最好本身就是已經熟悉 linux 操作的使用者

        不然遇到問題只能等待救援，一方無助、一方無奈，相互拖磨而已



        若沒有要掌握 docker，那其實也沒幾個指令

        會 load image，start, stop, restart 應該就能動了

        不然你幫忙包成 Web App 能 click click 完工也行

        (也許有現成的工具)



        單純作為 "user" 那也只是多認得一些指令，

        只是有沒有意願接收新知的問題。

        但考慮到不同平台的便利性，我個人比較選擇 vagrant + docker

        等 native docker 在 windows 大家都用得真正穩定後，

        才會考慮純 docker 的配置了



        先前公司部分專案有用到類似的環境，一開始是 docker。

        為了讓 windows 開發為主的同事使用，另外再包了一層 vagrant

        《Linking Error》
        https://speakerdeck.com/qrtt1/linking-error
        https://github.com/qrtt1/PyHUG20150303


    PS. docker 也有社團能參考
        https://www.facebook.com/groups/docker.taipei/?fref=ts

:  為什麼要問這個問題呢？
:  或許是因為我們這裡的管理者平常根本不寫程式，不會接觸這些開發環境，
:  所以要是我們批評某工具很難用、妨礙工作，希望可以換掉時，
:  他們通常很難體會開發人員的感受，不會就這樣買單。
:  他們搞不好還心想「別再抱怨了，請你就是要解決這種問題的，誰工作不曾覺得難受？」
:  當我跟老闆提案，想介紹這些工具進團隊時，
:  他們會在意新進人員能否順利上手？
:  如果不行的話，那公司又該投入多少資源訓練到OK？ 所謂的OK又是什麼程度？
:  使用這些工具是否容易不小心損壞東西？
:  導入有什麼效益？ 這些效益能否從會計的觀點量化成金錢，好讓他容易向更上級報告？
:  我得先準備好上述問題的答案再跟他們討論，這樣才容易成功，
:  不然他們可能只會笑一笑，心想「乖喔，我知道你很認真，但別再抱怨啦~」。
:  因此，我覺得「要不要用」反而不是導入 docker 的核心議題....答案實在太明確了。
:  舉凡「開發人員能否順利上手」、「能否整合進目前的軟硬體設施」、
:  「解決方案是否適合公司的環境」等等問題才是該多花時間思考的。
:  附帶一提，我覺得這些管理者都是很認真踏實經營事業的人，只是有時候比較死腦筋。
:  他們分析問題的觀點其實不算很多元，常常只會管理、營運和技術的角度切入事情。
:  當我從人力資源的角度向他們提倡「好工具是一種員工福利」時，
:  他們的反應不太熱絡，我猜是不太接受這種概念，甚至根本就聽不懂。
:  最近我正在準備相關資訊刺激他們，希望能夠誘導他們下適當的決定。


        這就...是公司內部的問題，沒什麼特別想回應的。




: :         即使 Docker 的 native support 已經有宣傳能在 Windows, OSX 使用
: :         但要到穩定好用不確定要再等多久，
: :         而你的情境多是 java 為主的話，要新人快速地從無到有建立開發環境
: :         在有提供手冊指引的話，沒道理一天搞不定啊
: :         （一定是有什麼我們所不知道的細節沒談到）
:  我從q大先前的文章推測你們開發人員的平均實力遠遠超過我們，
:  要是再考慮到你們使用比較好的開發工具，建置環境的手冊又比較同步的話，
:  我相信你們建置開發環境的速度一定很快，但我們就未必了....

        再重提一次，建置『部署環境』與『開發環境』的議題不太一樣。

        部署環境強調一致性，開發環境比較個人化。

        不太適合把這二個不同目標的事情放在一起搞，

        即使輔助的工具可能是重疊的，

        但沒看準目標就行動，肯定繞得路比較遠些。



        至於開發人員的實力，每個人擅長的不同。

        好的管理者與開發者的自覺，視情境把讓各自發揮出水準而已。

        而我們的開發環境，只要有 JDK 跟 Tomcat 就足夠了

        其他的個人必備工具，就看自己的喜好了

        有人用 IDE，有人不用 IDE，有人用 git cli 有人用 git GUI ...

        裝這些實在沒什麼難度，

        但我不能以我的情境去質疑你的時間，

        因為我們，或著說外人根本看不到實際的痛點在哪




--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.227.38.73
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1459741805.A.4B9.html
※ 編輯: qrtt1 (36.227.38.73), 04/04/2016 11:51:14
※ 編輯: qrtt1 (36.227.38.73), 04/04/2016 11:52:08
※ 編輯: qrtt1 (36.227.38.73), 04/04/2016 11:54:46
→ idleidle: DevOps就是事情變多，外面還認為你閒閒沒事整天坐在
→ idleidle: 電腦前上上網~看看網頁!
        以『終極、理想型態』的觀察來說，

        事情不會變多，反而應該要變少，但卻能做的得多。



        多是多在新的工具的導入與新觀點的學習，

        少是少在人工的介入與品質難以均一的人為操作。

      （取而代之的是，透過指令或 API 自動化或半自動化）



        原本在 server side 該學的知識不會變少，

        不過是否要學到深入是看個人職業取向與技能樹的點法

        為了維持事情的進展，有時我們可以選擇無知，

        並將事情委派給同事或其他服務。



        越搞越忙的情況，常是在新、舊交疊的時期，

        並且有不同的支持著互相拉扯，

        讓新的無法完全導入，舊的也無法完全退休

        （這種事只能靠戰績實力或政治解決囉）


推 dream1124: 再次謝謝你這麼認真的回覆!! 全部都有講到問題的核心!
→ dream1124: 就連玩笑話都很認真回, 我有一種目瞪口呆的感覺,哈哈
        驚！我對梗太深的笑話或反串常難以辨示 @@
※ 編輯: qrtt1 (36.227.38.73), 04/04/2016 16:16:58
※ 編輯: qrtt1 (36.227.38.73), 04/04/2016 16:19:18
→ dream1124: 把Log或Metric導出來接ELK stack,請問metric是什麼？
→ idleidle: 另一個觀點，資訊人員應該主動走出電腦前，多多跟使用者
→ idleidle: 進行互動，這樣得到"績效"比待在電腦前面C/P值高!
→ qrtt1: http://metrics.dropwizard.io/3.1.0/
推 bean0917: 感謝～大推