CICD概述
- CI-持續集成(Continuous Integration)：頻繁地將代碼集成到主干的一種開發實踐，每次集成都通過自動化的構建（包括編譯，發布，自動化測試）來驗證，從而盡早地發現集成錯誤。
- CD-持續部署(Continuous Deployment)：從代碼提交，自動化完成測試、構建及到生產環境的部署
在Rancher中做CI/CD的方法
- 配合第三方工具，Drone/Travis/Jenkins，配合webhook，rancher cli等觸發部署更新
- 使用
Rancher pipeline構建從源碼提交到Rancher中應用部署的一套流水線
Rancher pipeline的部署
Ranche Pipeline 是Rancher V1.6.13更新發布的新功能。所以如果不是V1.6.13首先要進行 Rancher的升級。
Rancher pipeline的安裝非常簡單，在應用商店搜索pipeline
用默認的配置一鍵部署
等基礎設施應用中pipeline中的服務都啟動后，就會在上方看到流水線的菜單出現
第一次打流水線時可能會因加載UI文件會慢一些，打開后的效果如下圖
授權git倉庫
選擇gitlab
按提示步驟設置gitlab
配置GitLab進行基於OAuth的身份驗證
生成了客戶端ID和秘鑰
填寫剛生成的客戶端ID和秘鑰，並添寫gitlab信息后驗證
授權
等待驗證
驗證成功
可以添加其他更多的帳號（gitlab要退出重新用其他帳號登陸）
GO DEMO
添加流水線
添加一個階段
mkdir -p /go/src/10.240.4.160/example
ln -s $(pwd) /go/src/10.240.4.160/example/go
cd /go/src/10.240.4.160/example/go/outyet
GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o bin/outyet
docker pull 10.240.4.159/example/outyet:demo
/data/tomcat/webapps:/usr/local/tomcat/webapps
https://github.com/golang/example
創建容器的時候指定啟動參數，自動掛載localtime文件到容器內
https://github.com/lawrli
##
/etc/localtime:/etc/localtime:ro
參考文檔：
將證書拷貝到如10.240.4.158客戶機上並信任
scp -P 50022 10.240.4.160.crt 10.240.4.158:/usr/local/share/ca-certificates/
mattermost_external_url ‘https://10.240.4.160‘
mattermost_nginx[‘redirect_http_to_https’] = true
mattermost[‘gitlab_auth_endpoint’] = “https://10.240.4.160/oauth/authorize“
mattermost[‘gitlab_token_endpoint’] = “https://10.240.4.160/oauth/token“
mattermost[‘gitlab_user_api_endpoint’] = “https://10.240.4.160/api/v4/user“
##
openssl req -new -newkey rsa:2048 -nodes -out 10.240.4.160.csr -keyout 10.240.4.160.key -subj "/C=CN/ST=Harbin/L=Harbin/O=ydgw/OU=IT/CN=10.240.4.160" openssl x509 -in 10.240.4.160.crt -text -noout cp 10.240.4.160.crt /usr/local/share/ca-certificates/ /data/dns-etc/resolv.dnsmasq:/etc/resolv.dnsmasq /data/dns-etc/dnsmasqhosts:/etc/dnsmasqhosts /data/dns-etc/dnsmasq.conf:/etc/dnsmasq.conf /etc/localtime:/etc/localtime:ro dns (Expected state running but got error: Error response from daemon: OCI runtime create failed: container_linux.go:296: starting container process caused "process_linux.go:398: container init caused \"rootfs_linux.go:58: mounting \\\"/data/docker-dns/dnsmasq.conf\\\" to rootfs \\\"/var/lib/docker/aufs/mnt/3daf5708bcea4ec8da7108e5c8d6b2d030010e5a1fbe7d86349dc3db1a3fd774\\\" at \\\"/var/lib/docker/aufs/mnt/3daf5708bcea4ec8da7108e5c8d6b2d030010e5a1fbe7d86349dc3db1a3fd774/etc/dnsmasq.conf\\\" caused \\\"not a directory\\\"\"": unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type) docker run -d -p 53:53/tcp -p 53:53/udp --cap-add=NET_ADMIN --name dns-server andyshinn/dnsmasq docker pull andyshinn/dnsmasq mkdir -p /data/docker-dns cd /data/docker-dns vi resolv.dnsmasq nameserver 202.97.224.68 nameserver 114.114.114.114 nameserver 8.8.8.8 vi dnsmasqhosts 10.240.4.160 gitlab gitlab.ydgw.cn vi dnsmasq.conf resolv-file=/etc/dnsmasq.d/resolv.dnsmasq addn-hosts=/etc/dnsmasq.d/dnsmasqhosts resolv-file=/etc/dnsmasq.d/resolv.dnsmasq addn-hosts=/etc/dnsmasq.d/dnsmasqhosts docker tag SOURCE_IMAGE[:TAG] 10.240.4.159/app/IMAGE[:TAG] docker-compose -f ./dns.yaml up -d
容器-Docker為什么火？
Google自2004年就開始使用容器技術，目前他們每周要啟動超過20億個容器，每秒種新啟動的容器就超過3000個，在容器技術方面有大量的積累。
曾相繼開源了Cgroup(Control Groups)和Imctfy(Google開源Linux容器)這兩個重量級項目。Google對Docker的支持力度非常大，不僅把imctfy先進之處融入Docker之中，還把自已的容器管理系統(kubernetes)也開源出來。
技術的發展產生了大量優秀的系統和軟件。
操作系統：Redhat/Centos、Debian/Ubuntu、FreeBSD、SUSE等
編程語言：Java、Python、Ruby、Golang、C/C++等
WEB服務器：Apache、Nginx、Lighttpd等
數據庫：Mysql、Redis、Mongodb等
軟件開發人員在這么多種類中自由選擇，結果就是維護一個非常龐大的開發、測試和生產環境，開發、測試和運維人員就會被種類繁多的環境折騰的筋疲力盡。即使只選擇其中一兩種，隨着操作系統和軟件版本的更新迭代，維護工作還是變得越來越龐大。