とことんDevOps | 日本仮想化技術のDevOps技術情報メディア

DevOpsに関連する技術情報を幅広く提供していきます。

日本仮想化技術がお届けする「とことんDevOps」では、DevOpsに関する技術情報や、日々のDevOps業務の中での検証結果、TipsなどDevOpsのお役立ち情報をお届けします。
主なテーマ: DevOps、CI/CD、コンテナ開発、IaCなど

開催予定の勉強会

読者登録と各種SNSのフォローもよろしくお願いいたします。

イベントレポート 第10回とことんDevOps勉強会 拡張版「DevOpsの始め方講座 - 2023年度こそDevOpsを始めよう!」

今回はキリの良い第10回ということと、もうすぐ新年度ということで、2時間の拡大版でお送りしました。「DevOpsの始め方講座 - 2023年度こそDevOpsを始めよう!」というタイトルで、DevOpsを始めるために必要な要素を技術的観点とプロジェクト運営的観点から紹介しました。技術的観点では、CI/CDの観点、実行インフラの観点、クライアント開発環境の観点から、DevOpsを学ぶためのスタート地点としての技術を紹介しました。また、プロジェクト運営の観点からは、今までお客様から頂いた相談内容を紹介しながら、DevOpsの必要性やDevOpsプロジェクトのはじめ方を紹介しました。

また、最後に日本仮想化技術が提供するサービス「かんたんDevOps」の正式リリースを記念して先着3社に無償で簡単DevOpsを提供するキャンペーンを発表しました。詳しくは下記のリンクを参照ください。

virtualtech.jp

加えて、DevOpsでの開発プロセスを体験できる無償のワークショップを4月から提供することも発表しました。

virtualtech.jp

振り返りも兼ねて当日の配信の様子をYoutubeでアーカイブしていますので、是非ご覧ください。当日参加できなかった方も、これを機会にとことんDevOps勉強会に興味を持っていただければと思います。また、当日いただいたQ&Aに関してもこちらのブログでまとめていますので、ぜひご覧ください。

セミナー動画 - YouTube Live アーカイブ

www.youtube.com

発表資料 - Speaker Deck

第1部導入、第2部

speakerdeck.com

第1部 ここから始めるDevOps CI/CD編

speakerdeck.com

第1部 ここから始めるDevOps 実行インフラ編

speakerdeck.com

第1部 ここから始めるDevOps クライアント開発環境編

speakerdeck.com

 

Q&Aまとめ

Q: データベースのブルーグリーンデプロイメントの仕方を知りたいです。

 

A: データベースの変更の自動化は自動化の中で最も難しい分野だと思います。データの持ち方や更新頻度によってやり方が異なってくるかと思います。テスト用にレプリケーションしたデータを使うなどといった方法も考えられますが、明確な答えが出しづらいご質問です。

Q: インフラの自動化、大変な割に何回も実行するわけではないので、どこまでIaCすべきか悩みます

 

A: インフラの自動化に関してはできる限り行った方が良いと思います。自動化しないまでも、コード化は行うべきです。手順書などで記述するよりも、正確に情報を残すことができます。

Q: 本番リリースまで完全自動化することはできるのでしょうか?

 

A: やるかやらないかは別として、できます。リリース頻度が低かったり、人が最終確認したい場合などは、完全自動化をしないことも多いです。逆に1時間に1回リースするような頻度であれば、完全に自動化する必要があると思います。

Q: ArgoCDの認証情報を外部に出さないでもいい、というのが少しイメージできなかった。クラスター上で動作している方がデプロイがしやすいということ?

 

A: ArgoCDを使わないでCircleCIなどでデプロイする場合は、KubectlやHelmなどのコマンドを実行するために、CircleCI側に認証情報を持たなければいけません。また、ArgoCDがクラスタ内で稼働することでクラスタの状態をArgoCDの画面から確認することもできる点がメリットです。

Q: Terraform、よく耳にするのですが、学習のしやすさや使いやすさの点でどう評価していますか?

 

A: 最近ではTerraformがCloudを操作するデファクトになりつつあります。使いやすさでいうと、HashiCorpが運営しているTerraform Cloudを使用するのが便利です。ただし、ループ処理の可読性は非常に悪いのが難点です。

Q: Kubernetesについて、アプリケーション一台動かすのに、サーバー6台使うという補足がありましたが、なぜ、6台必要なのか理解できなかったので、なぜ必要なのか教えていただけるでしょうか
 
A: Kubernetesを動かすだけなら1台でも動きます。ただし、クラスタを構成して冗長性を持たせるにはコントロールブレーンで3台、ワーカーノードで3台が必要になります。クラスターを組む必要がないような規模の小さなアプリケーションの場合には、あえてKubernetesで構築しなくても良いと思います。

Q: DDLの本番リリース自動化の実現、また失敗時のリカバリの方法について知りたいです。システム停止をしないで、DDLのリリースをしたいのですが、どのような方法がありますか?

 

A: 最初の質問と同様に、非常に難しいご質問ですね。alter tableをするようなパターンもあれば、別のテーブルを作ってリレーションを貼る、さらにはViewを作るようなパターンも考えられます。いずれにしても、アプリケーションの変更に伴う不可逆的な変更はできるだけ避けるようにする必要があります。そのため、DDLのレベルでデータ構造を変えるのではなく、アプリケーションのレイヤーでデータ構造の変更を隠蔽できることが望ましいと思います。あと、テストをしっかり行うということは必須ではあります。

Q: docker fileにGitからライブラリをインストールするスクリプトを書いて、そのdocker fileをオフライン環境で実行してコンテナを作った場合、そのライブラリは使えるのでしょうか?

 

A: リモートリポジトリから取得するという前提で、ビルド済みのコンテナをオフライン使うのであれば使えると思いますが、オフラインでビルドをするような場合はGit cloneのタイミングで失敗すると思います。