![インベントリファイル
[webservers]
192.168.33.10
[dbservers]
192.168.33.11
ファイルの例
プレイブック
- name: 全環境に適応するプレイブック
hosts: all
tasks:
- name: install open-jdk
yum: name=java-1.8.0-openjdk-headless.x86_64 state=present](https://image.slidesharecdn.com/it-171109024845/85/IT-76-320.jpg)
![パイプライン（制御コードの書き方）
参考資料：https://github.com/sh-ogawa/jenkins-files/blob/master/junit-sonar-
script/Jenkinsfile
node {
stage('update') {
git([url: 'https://github.com/sh-ogawa/auto-test-demo.git', branch: 'sonar'])
}
stage('test') {
bat 'mvn clean jacoco:prepare-agent test jacoco:report -e | echo "ignore failure"'
}
stage('analyze') {
bat 'mvn sonar:sonar -e'
}
}](https://image.slidesharecdn.com/it-171109024845/85/IT-103-320.jpg)
![パイプライン（制御コードの書き方）
参考資料：https://github.com/sh-ogawa/jenkins-files/blob/master/junit-sonar-
script/Jenkinsfile
node {
stage('update') {
git([url: 'https://github.com/sh-ogawa/auto-test-demo.git', branch: 'sonar'])
}
stage('test') {
bat 'mvn clean jacoco:prepare-agent test jacoco:report -e | echo "ignore failure"'
}
stage('analyze') {
bat 'mvn sonar:sonar -e'
}
}
使用するCIツールによって書き方は勿論違うけど、
基本的にリファレンス見ながら書くだけなので、実行自体は難しくない。
※難しい（というか手間がかかる）のは、その中身の制御（AnsibleのプレイブックとかDockerfile）を書くこと。
ちなみに例のJenkinsパイプラインスクリプトはGroovy（私Groovyなど書いたことないですが、これは書けます）](https://image.slidesharecdn.com/it-171109024845/85/IT-104-320.jpg)
More Related Content
Similar to 滨罢の开発现场における最近の当たり前これからの当たり前（主観） (20)
More from 小川 昌吾 (20)
滨罢の开発现场における最近の当たり前これからの当たり前（主観）
- 5. 駆け足???
- 8. で、お前何が判るの？
- 9. DevOps歴 ■ DevOps完遂経験は勿論ない ■ CIは2011年くらいから ■ 颁顿は2014年くらいから（シェルだった）
- 10. 顿别惫翱辫蝉とは
- 11. 顿别惫翱辫蝉???それは思想
- 15. 対立している???
- 18. それも速く
- 20. DevOps = ツール + 組織文化
- 21. DevOpsツール ■ インフラ構築を自動化するためのもの ■ 開発と保守を並行で行うためのバージョン管理 ■ ワンステップビルド＆デプロイ ■ フィーチャーフラグで機能の有効無効を制御 ■ ソフトウェアメトリクスの共有 ■ Botやモニタリングによるアラート検知
- 22. DevOpsツール ■ インフラ構築を自動化するためのもの →ansible ■ 開発と保守を並行で行うためのバージョン管理 →git ■ ワンステップビルド＆デプロイ →CI tools(Jenkins, TravisCI、CircleCI、etc) ■ フィーチャーフラグで機能の有効無効を制御 →実装レベルでの制御 ■ ソフトウェアメトリクスの共有 →SonarQube ■ Botやモニタリングによるアラート検知 →slack、zabbix、prometheus、mackerel、etc
- 23. DevOpsツール ■ インフラ構築を自動化するためのもの →ansible ■ 開発と保守を並行で行うためのバージョン管理 →git ■ ワンステップビルド＆デプロイ →CI tools(Jenkins, TravisCI、CircleCI、etc) ■ フィーチャーフラグで機能の有効無効を制御 →実装レベルでの制御 ■ ソフトウェアメトリクスの共有 →SonarQube ■ Botやモニタリングによるアラート検知 →slack、zabbix、prometheus、mackerel、etc
- 24. DevOps 分化 ■ お互いを尊重する ■ お互いを信頼する ■ 失敗に対して健全な態度を取る ■ 相手を非難しない
- 25. DevOps 分化 ■ お互いを尊重する ■ お互いを信頼する ■ 失敗に対して健全な態度を取る ■ 相手を非難しない 賢者かよ！？って感じの項目が並んでますが、 外から来た目で見て、 かなりできているように視えてます（すごい！）
- 27. 本题
- 28. 颁滨から～
- 31. 意味不明( ；?Д｀)
- 34. リリースすることによってかかる費用 ■ バグフィックス ■ 機能追加 ■ サーバー運用費 ■ トラブル対応 ■ 利用者へのサポート etc...
- 38. だが、人类には自动テストがある！
- 44. 自動テストをやる理由 ■ 新しく入ってきた人にシステムを託すため ■ ソフトウェアの振る舞いが変わったことを検知するため ■ レグレッションテストで楽したい（开発者目线）
- 45. 自動テストをやる理由 ■ 新しく入ってきた人にシステムを託すため →動くもので仕様を把握できる ■ ソフトウェアの振る舞いが変わったことを検知するため →カバレッジの変化で思わぬ変更を捕捉する ■ レグレッションテストで楽したい（开発者目线） →毎回行う儀式的な確認からの解放
- 47. /** * @test */ public function 足し算の確認() { $test_class = new Target(); $this->assertEquals(3, $test_class->add(1, 2)); }
- 48. /** * @test */ public function 足し算の確認() { $test_class = new Target(); $this->assertEquals(3, $test_class->add(1, 2)); }
- 51. なぜか？
- 53. だからテスト専用机にやらせる
- 54. 颁滨サーバー
- 56. 无人だから谁もストレスに感じない
- 57. 颁滨サーバーにやらせること ■ セントラルリポジトリにチェックインされたコードの自動テ ストの実行 （プルリク時にテストさせることも可能） ■ テスト結果のレポーティング ■ 厂濒补肠办などへ结果を通知
- 61. なのでリリースを自动化する
- 62. 颁顿の出番！
- 67. 骋颈迟のブランチを活用する
- 69. ブランチの基本セット (Githubフローもこんな感じ) ■ 機能の開発：feature,hotfix,issueなど ■ 開発用マスタ：version番号 ■ 結合環境：develop ■ 本番相当の確認環境：staging ■ 本番環境：production ■ 最近無くても良い気がしてきた：master
- 73. Ansible
- 76. インベントリファイル [webservers] 192.168.33.10 [dbservers] 192.168.33.11 ファイルの例 プレイブック - name: 全環境に適応するプレイブック hosts: all tasks: - name: install open-jdk yum: name=java-1.8.0-openjdk-headless.x86_64 state=present
- 79. Ansibleの位置付け ■ インフラのコード化が捗る ■ インフラを構築するための便利なシェル if $?とかしなくて翱碍
- 80. どこまで细かくイケる？
- 81. Ansibleで対応できること ■ システム１つ丸々構築できる ■ WEBサーバーだけ、DBサーバーだけ、限定的に構築可能 ■ AWSのEC2も作れる ■ 設定ファイルは上書きから、特定の行の変更、付け足しなど 割と何でもできる
- 83. 厂别谤惫别谤蝉辫别肠を使う
- 84. Serverspecでできること ■ ミドルウェアが入っているか ■ サービスが登録されているか ■ 正しいポート番号でリッスンしているか ■ 構成ファイルが存在しているか など
- 87. Serverspecでできること ■ ミドルウェアが入っているか ■ サービスが登録されているか ■ 正しいポート番号でリッスンしているか ■ 構成ファイルが存在しているか など これくらい確認しとけば十分
- 92. 一旦まとめ
- 93. CI（継続的インテグレーション） ■ ソフトウェアの品質を維持するためのプラクティス これ自体が何かするわけではない ■ テストコードを書いておくと、好きな方法で実行できる ■ 顿别惫翱辫蝉のハブである
- 94. CD（継続的デリバリー） ■ 好きなときに、実行可能なソフトをリリースするプラクティス ■ 類似のもので、定常的にリリースをし続ける 継続的デプロイメントがある ※海外だと何となくこちらの意味合いの方が強そう ■ 颁滨から起动される
- 95. ぶっちゃけ???
- 97. 今现在は、「パイプライン」が主流
- 99. パイプラインのジョブとは ■ SCMからチェックアウト ■ テストコードを実行 ■ テストコードの結果とカバレッジの保存 ■ ソフトウェアのデプロイ ■ インフラの構築 ■ Dockerコンテナのビルド ■ 任意シェルの実行 など、コマンドでできること全て
- 100. パイプラインのジョブとは ■ SCMからチェックアウト ■ テストコードを実行 ■ テストコードの結果とカバレッジの保存 ■ ソフトウェアのデプロイ ■ インフラの構築 ■ Dockerコンテナのビルド ■ 任意シェルの実行 など、コマンドでできること全て
- 103. パイプライン（制御コードの書き方） 参考資料：https://github.com/sh-ogawa/jenkins-files/blob/master/junit-sonar- script/Jenkinsfile node { stage('update') { git([url: 'https://github.com/sh-ogawa/auto-test-demo.git', branch: 'sonar']) } stage('test') { bat 'mvn clean jacoco:prepare-agent test jacoco:report -e | echo "ignore failure"' } stage('analyze') { bat 'mvn sonar:sonar -e' } }
- 104. パイプライン（制御コードの書き方） 参考資料：https://github.com/sh-ogawa/jenkins-files/blob/master/junit-sonar- script/Jenkinsfile node { stage('update') { git([url: 'https://github.com/sh-ogawa/auto-test-demo.git', branch: 'sonar']) } stage('test') { bat 'mvn clean jacoco:prepare-agent test jacoco:report -e | echo "ignore failure"' } stage('analyze') { bat 'mvn sonar:sonar -e' } } 使用するCIツールによって書き方は勿論違うけど、 基本的にリファレンス見ながら書くだけなので、実行自体は難しくない。 ※難しい（というか手間がかかる）のは、その中身の制御（AnsibleのプレイブックとかDockerfile）を書くこと。 ちなみに例のJenkinsパイプラインスクリプトはGroovy（私Groovyなど書いたことないですが、これは書けます）
- 105. パイプライン（実行のさせ方）
- 106. パイプラインの良いところ ■ SCMで管理可能 ■ コードで記載されているから何をやっているかも雰囲気で判る ■ タスクが死んだ场合、どこで死んだか一目で判る
- 107. パイプラインを使わない手はないです
- 109. 従来 ApachePHP MySQL
- 110. 似たような作业が毎回発生
- 117. 各種アップデ ートよろお
- 119. クラウドを前提としたときのあるべき姿 Vagrant Ansible このとき、PHPUnitでテストコードを入念に 書いていると、テストコードを実行するだけ で、１次診断が終わる。（超時短）
- 121. 新しくサーバーを作るのがミソ
- 125. 缓募：一绪にやる人
- 128. なので、みんな础苍蝉颈产濒别やろう！
- 129. ご静聴ありがとうございました。
Editor's Notes
- #82: これがinfrastructure as codeって巷で言われている領域
- #91: インフラエンジニアは、各社クラウドが出してくる新サービスへの追随で忙しくないとイケない インフラのロールモデル的には、最低２つ以上のクラウドに精通することが今後の条件になってくると思ってる。
- #103: どこでコケタかが判る。 これが無いと垂れ流しのテキストログから死んだところを特定するところから探さなくてはいけなくダルイ。
- #108: 厂别谤惫别谤蝉辫别肠は一旦どうでも良いです。
- #109: 厂别谤惫别谤蝉辫别肠は一旦どうでも良いです。
- #111: 厂别谤惫别谤蝉辫别肠は一旦どうでも良いです。
- #113: 厂别谤惫别谤蝉辫别肠は一旦どうでも良いです。
- #122: サーバーは動かし続けていれば、何れかリソースを消費していく。 これを防ぐときは、オンプレなら再起動を行うが、クラウドの場合は、サーバーを取り換える
- #126: いきなり话を戻しますが???