哈哈，轉po了一則個人欣賞時鐘先生的平靜與耐力文，又出現了很多網軍...可以讓我們用來做精神伸展肌肉按摩練習用（喜）
有了精神伸展肌肉按摩，也不要忘記身體的鍛鍊呦！
來來來，這就來邀請同學和馮云跟著Hibi老師一起每週兩次線上正位瑜伽呦！
✔️ 適量而正確的運動提高免疫力
✔️ 好好在家運動很簡單
✔️ 就聽老師安排就能完成了超有感的訓練
6/26 (六）pm4:00-5:15
6/29 (二）pm7:00-8:15
7/04 (六）pm4:00-5:15
7/06 (二）pm7:00-8:15
.
▍一堂600元＋送▹好好購物金100元
▍一次兩堂1200元＋送▹好好購物金300元
▍一次報三堂1800＋送▹好好購物金500元
▍一次報四堂2400＋送▹好好購物金800元
⭕️希望能鼓勵大家防疫期間持續好好運動
一堂滿4人就開課，最多8人
.
老師要求品質，所以名額超級少，以報名優先順序為主，滿了就沒嘍～想來一起運動的同學務必儘早報名 https://reurl.cc/1Y3MnQ
自從5/17三級防疫之後，持續了大半年的正位瑜伽實體課改線上瑜伽課，我才發現Hibi老師的正位瑜伽真的很適合上線上：
口齒清晰，動作指令清楚，動作緩且不複雜，肌力訓練伸展拉筋能在一堂課中都一次練習到，線上課又省時間與交通，相當完美～
.
Hibi老師會透過螢幕幫每位同學細看動作（所以人數才只能8人）
課前課後都有冥想正念，可以穩定最近亂亂慌慌的心神
我每次做完都覺得變得很有活力～很好。
個人建議一週至少上一次（一週二次更精實些）
運動，就是要持續才有效果～
.
✔️正位瑜伽是什麼？
正位瑜伽在練習的過程中
會給予身體更多的細節
引導回歸身體的本位
著重肢體如何細緻的去保持在正確位置、方向
從根基調整，引導骨盆、脊椎和肩關節回到正位
動作看似單純緩慢 卻需要很專注的肌力
所以可以鍛鍊到重訓或伸展到達不了的深層肌群活化
鍛鍊並逐步建立深層的肌力與柔軟度
課程將包含精冥想引導並融入呼吸法
站姿、前彎、後彎、扭轉 伸展等元素
.
✔️ Hibi 老師
2017 RYT-200 with Michael Jenkins & Sucharita Hsu
2017 7th Annual Residential Retreat with Rina Ortiz (Manila)
2017 艾揚格高階研習營（15 hrs）
瑜珈境，Zubin Zarthoshtimanesh指導
2018 艾揚格瑜珈根基課（120 hrs）
禪圓瑜珈，Sri Nandakurma指導
2019 透過瑜珈探索五大元素(15hrs)
禪圓瑜珈，Olop Arpipi指導｜
.
報名完後，我們陸續依照報名順序通知同學是否有報名成功，然後幫你加入課程line群，上課使用Zoom軟體（會引導你下載）
上課用手機或電腦都可。
.
✔️上課要準備
瑜珈墊，毛巾，水，瑜伽磚（初期可用書本代替），瑜珈繩（不一定會用，沒有的人可以用毛巾代替），最好自然風或電風扇
＊因為會流汗，冷氣房容易著涼
.
若沒有瑜珈墊或磚的同學，可以在下面購買
.
✔️森之旅葡萄牙軟木瑜珈墊
https://reurl.cc/rgDLNb
瑜珈墊我私心推這個，雖然比較貴，但用了就回不去了，不過久了會壞，我已經因為汗滴太多（運動量是有多大），四年多來已經用壞兩張了
如果有預算限制，可以考慮這個
✔️心之流小甦醒瑜珈墊(5mm)
https://reurl.cc/vqd73l
我用了覺得有點薄，跪的動作要墊毛巾才行，可能我已經習慣軟木的厚度了（由奢入簡難啊）
.
✔️軟木瑜伽磚
https://reurl.cc/Enro8n
這個很推，瑜伽磚可以用很久很久～用途很廣。
.
提醒要提早買呦（最近黑貓快遞塞車中，不一定可以隔日送達）
想來的同學趕快先報呦，先報名收到通知再繳費。
我們週六正位瑜珈中見嘍❤
jenkins用途 在 [請益] 自動化佈署(Chef, Ansible, Salt) - 看板Soft_Job - 批踢踢 ... 的推薦與評價
※ 引述《Sanbeishuu (三杯鼠)》之銘言：
: 請問主流的幾款自動化佈署軟體有無較適合單純的update某個web application的呢?
[--------] [-----------------------]
update 這確實很容易，但事情不是只有 update
你現在只想到 {自動化, 部署}
不是真的 {自動化部署} 完整的思維應該是 delivery pipeline
自動化不是必要的，但要完全「非人工」介入，
並讓每一個程序可以被追蹤，得付出額外的努力。
當你真的做到「完善」的時候，
你要做的事就不是單純你現在描述的這些內容了。
可以先看個入門學，培養一下概念
https://www.books.com.tw/products/0010653820
https://www.thoughtworks.com/continuous-delivery
(由於成書至今有些年份，工具可能改朝換代，
或 DVCS 的接受度有變，那就依自己的情境代換一下吧。)
: 一開始試了Jenkins，發現他好像不是這樣的用途。後來才發現應該是其他的像是
: Puppet, Chef, SaltStack, Ansible, Juju?
Jenkins 最初大家拿它來做測試為主，
並因為是基於 jvm 為主的應用程式，所以拿它來控制各種平台的活動
實在非常方便，所以才有用它的 agent 在常見的 Linux, Windows, OSX
上配合與不同的 Browser 組合互相試測（配合 selenium 更是如虎添翼）
甚至到現在，加上 android device 或 iOS device 的自動化測試依然也適用。
對它來說，工作的「單位」都是 Job，只要有安裝上 java agent
（在防火牆內還可以透過 JNLP 由 node 上連回 jenkins master）
就能輕鬆遞送要做的工作。
Jenkins 比較適合在 node 數固定，且混雜異質平態，需高度客製化的情境。
因為 "Job" 的內容很多變，可以是 Ant Job、Maven Job、Gradle Job
或沒限制你寫什麼的 FreeStyle Job，你想改什麼，或呼叫端遠指令都做得到。
不過要寫成這樣，已經跟「高度」客製化沒什麼差別了啊。
（這隱含著，你目標的環境並沒有「整理」成較一致的情況）
不過，到了 2.x 要準備發佈的這個時代，加上「雲端」與
Continuous Delivery 概念與 DevOps 哲學觀的推擠，
它開始將 workflow 的概念合併改名字為 Delivery Pipeline 的 Pipeline。
也就是你一個完整的軟體開發流程的「管線 (pipeline)」是怎麼串起來的
1. 開發者把程式送往 VCS
2. VCS 的程式被拿來 Build 成 Artifact
3. Artifact 被拿來跑單元測試
4. Artifact 加上 Configuration 丟上 UAT 跑整合測試
5. UAT 跑過後，送上 Staging 跑整合測試與煙霧測試(smoke test)
6. 通過各種測後，進行 release 的 workflow
這整個 workflow 的每一階段都是 1 個 pipeline
pipeline 內可以是另一個 pipeline 或實際執行的步驟。
且每 1 輪的 workflow 的發起都會對上 VCS 的 revision
release 的 workflow 會是某個標示通過測試的 artifact
（你會有 jenkins build number 與知道它是哪個 revision）
以你的情況，可能是某個 war 或 jar
會在 prod 上 deploy 並進行煙霧測試，確定狀態良好後開始服務
不然就維持舊的版本
==========================================================
Puppet, Chef, SaltStack, Ansible 則是不同的動機而起的，
雖然目前比較「紅」的詞是 DevOps，但應該回到最初的想法去看它
他們該做的是 Configuration Management 這個工作。
但有個尷尬的問題是，你得先面對一個「選擇題」。
在 Continuous Delivery 書上，它的想法是
一個應用程式的良好運作是建立在 {組態設定、程式、資料} 三者都正確的情況
並且認為 {組態設定} 應獨位於程式，它的建議是 {組態設定}
不會包含在 Build 與 Package 內，應該獨立於它之外。
以這個邏輯來說，應該上組態的時間點在 Deploy 或 Provision 的時候。
而 Puppet, Chef, SaltStack, Ansible 正好是在做這件事的最佳助手
能幫檢查設定檔在不在、程式的狀態是不是在期望的狀態等等
他們的用法多為「描述一種最終的狀態」並且試著修正不合預期的狀態
尷尬的部分是，在 Java EE 的規範是把 {組態設定} 也封狀進 WAR 內的
我並不會說書上那麼建議，就一定要遵守，最適合的情況，
只有身處於那個工作場域的人自己知道。
以我目前的情境是比較傾向於把 {組態設定} 包進去的，
對我來說，來自同一個 revision 建出來的東西好追蹤比較重要
同一個 team 的開發者，不用多認識其他 tool 就能建出一樣的結果
這樣也同時能減少 {組態設定} 管理不當的意外。
因為二組 repo 可能會不好對上，
不管是 cfg 的 revision 沒跟上，或是 project 的 revison 沒跟上，
都可能有意外發生，或是 deploy process 失敗了，因為要 deploy 二次，
一次是 project 本身，一次是 {組態設定} 本身。
由於 DevOps tool 自己另一組 VCS repo 管理，
若是硬分割至各專案內，就變得難以看清楚
Infrastructure as Code 的全貌，除非剛好它們有機會共用一個 repo
且不會意外形成 duplicated code 那會是個較佳的型式。
(或是區分開來系統層面的 Automation 與專案元件的區分開來也是個辦法)
另外，不包進去，也不另外透過 deploy 程序來更新組態設定的話，
第 3 條路就是 service discovery 的方法了
(應該是書上第 2 部，講組態管理有提到這概念)，
通常就是跑個 agent 讓你問現在的設定。
像 EC2 在機器內部提供的 metadata
https://amzn.to/2cLJW4a
現在有 https://www.consul.io/ 這類的工具能做到
（但以你的情況需求 "portable" 大概不會採用 :P）
用這東西確實能讓你把組態抽出來，不過實際是否真的需要那麼「彈性」
是存疑的，過度的彈性與靈活，會造成「設置困難」，
每個選項間可能又有相依關係，這也許會搞死新進的開發者，
或是終於使用者根本無法利用這些「彈性」的設計。
: 目前看起來1跟2是Ruby派，3跟4是Python派，小弟是純Java派，所以沒特別偏好。
: 但如果可以的話是傾向Py派，但其實各款的script好像也不一定是用Py或Ruby寫..
: 主要使用情境如下:
: 1. Standalone & portable
: 希望是可以單純locally的去run，run這一台機器本身的deployment。
: 貌似這類軟體都是為了cloud management，所以都有server/client的架構。
: 目前只先略略survey了Chef，應該是有單純Chef-client跑CookBook的功能。
: SaltStack有看到masterless跟standalone的documentation的樣子。
: 另外還希望這是可以portable的，也就是我可以調整好script後打包起來，
: 然後交給客戶在on-premises的情境下，double click去完成deployment。
要讓客戶去 double-click 不覺得跟標題的「自動化」有點違悖嗎 :P
或許我該先忘記 double-click 或是「自動化」其中一個提前。
假設，我捨棄了「自動化」，讓客戶 double-click 的話，
又能 portable、又不可以另外裝些什麼軟體
那我該做些什麼呢？
弄個 executable JAR 做：
1. 下載最新的 WAR 回來（executable JAR 內知道 revsion => artifact）
2. 開一台 embedded Tomcat 跑這個 WAR (如果要改組態的話，也改吧)
3. 開始做 smoke test 確認重要的功能都可以動 (至少 DB 要連得上)
4. 如果有問題就，send log 回來
5. 如果沒問題就換上新版的至 prod
(這其實沒有像一些不上 store 的 andoird app 給你個 apk
它是讓你下載另一個 apk 用的!?)
如果我捨棄的是 double click。首先，為什麼要捨棄 double click 呢！？
因為客服可能收到了你「最新」的安裝檔，但卻執行了「舊的」安裝檔，
然後再寫信問你為什麼不 work。
其實 double click 不是主因，是人工判斷的品質差異比較大，
有可能他半夜被 call 來換檔（可能是加班，或不同時區），不小心點錯了
也可能是他沒有點錯，但我方給錯了版本。
至少，把品質放在人少的那一方比較好控制，
你可以把那個要 double click 的檔變成 windows service，
定期去查有沒有新的更新，有的話就執行更新程式
(這不就是 windows update 嗎？)
PS. 千萬不要把更新程式與 tomcat 綁在一起
你無法預知，你上新版後 tomcat 是不是會被你弄死
萬一綁在一起了，他們就只好殉情了
(其實 AWS 的 Beanstalk 也是弄個 hostmanager 的 agnet 做這件事啊)
PS. 不管你選擇的是什麼，都得能方便的知道使用者現行的版本
例如在 http response 加上特殊 header 標上各 component 的 revision
: 2. 只單純的deploy一個Java web application到tomcat
: 沒有要做複雜的server setup跟provisioning。想達到的其實只是單純的
: upgrade某個web application而已。所以整個flow有點類似以下這樣
: 已經有一個application跑在tomcat。該application有a.xml跟b.properties檔案
: a.xml的內容會類似如下
: <Property>
: <Name>ServerURL</Name>
: <Value>192.168.1.2</Value>
: </Property>
: b.properties的內容會類似如下
: database.host=192.168.112.25
: database.port=5432
: 有一個新的版本出來了，當然他是一個war檔。war檔內一樣有a.xml跟b.properties
: 只是這時war檔內的這些configure値會是default狀態。例如:
: <Property>
: <Name>ServerURL</Name>
: <Value>localhost</Value>
: </Property>
: database.host=127.0.0.1
: database.port=5432
: 自動化的把war檔解壓，將a.xml跟b.properties內容與正在運行的
: application有不同的地方做更改。然後可能必須在壓回去war包，
: call tomcat的rest API去進行deploy，如此將web app upgrade，
: 又不需要人工去處理這些application properties的設定値。
如果你只是要簡單的換 IP ... 那不如改 local host 對應的設定
C:\Windows\System32\drivers\etc\hosts
: 3. Windows platform
: Tomcat跑在Windows平台上(Win7, Win10, Win Server 2008, 2012 etc..)
: 所以等於是master跟client或者說standalone的運行是在Windows平台上。
: Chef有Windows的msi安裝檔，還沒確定是否可以portable的包起來。
: SaltStack的getting started doc都是Linux版本的範例..
很遺憾的，這些程式最初的開發者都不是 Windows User。
即使用提供，因為開發者人不夠多，用的人也不夠多
待「踩雷」的點應該很多，需要有「愛」才用得下去，
或是加入改善它們的行列吧！
: 4. Free~
: 目前看到Chef, Ansible, SaltStack都有付費版本或者提供SaaS。
: 但應該都有真正的freeware版吧? Ansible看不太出來
: 只有一個Ansible Tower Free trial
: 不知道有沒有大大可以建議一下哪一款比較適合簡單的達到這個的佈署呢?
: 感謝
看來看去，是前一篇大大自己 deploy tool 對你來說最適合。
或是問問其他 windows 深度使用的管理者，看看有沒有好招！？
我們現行的 deploy tool 也跟他相似，不過是仿 AWS Beanstalk
指定 revision 後，deploy 至各機器上
（但沒有做 agent 是 rsync 去遞送 + ssh remote command）
不過隨著系統的環境，與 project 整理的越來越一致，
之後應該會轉移至 ansible 上，透過它 deploy。
--
JCConf 工商服務
https://www.facebook.com/jcconf/posts/974947969317750
JCConf 2016 售票至 10/9 (日) 結束呦 :D
報名網址：https://twjug.kktix.cc/events/jcconf2016-register
議程網址：https://jcconf.tw/2016/
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 211.21.157.224
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1475483798.A.9C0.html
... <看更多>