インフラエンジニアによるブログですが、アプリケーションやセキュリティなど様々な話題を扱います。
この記事はGWアドベントカレンダーの8日目の記事です。
GitLabのパイプラインでdocker loginしようとすると以下のエラーで失敗しました。
docker -l debug login -u gitlab-ci-token -p ${CI_BUILD_TOKEN} http://${CI_REGISTRY}
Error response from daemon: Get https://xxx.xxx.xxx.xxx:4567/v2/: http: server gave HTTP response to HTTPS client
以下にあるdaemon.jsonの設定をrunnerに追加することで解決しました。 registryをHTTPS化することも考えましたが、このregistryがリバースプロキシ配下になく、一旦HTTPのままで対処しました。
この記事はGWアドベントカレンダーの7日目の記事です。
「Ansible 実践ガイド 第3版」を読みました。 この本は、これからAnsibleを始めようとする方や少し触ってみたものの、実際の環境にどのように適用すべきか検討し始めたくらいの方に最適と思います。 ただ、既に色々とAnsibleを適用しているものの構成が複雑で保守しづらくなってしまうというような方にも向いていると思います。 具体的なプレイブックの例がいくつも紹介されており、それぞれにプレイブックのノウハウがあります。
AnsibleやYAMLについての基本的な説明から始まっていて、その後具体的なプレイブックの紹介や保守性を考慮したディレクトリ構成等の実践的な内容へと移っていきます。 プレイブックのデバッグ方法についても様々な手法が説明されており、Ansibleを利用していく上で必要なことが一通り学べるようになっていると思います。
この記事はGWアドベントカレンダーの6日目の記事です。
IaCに関連する最近読んだ本の紹介です。 読んだ順に書いていますが、Ansible実践ガイドはまだ記事を書いていないのでここで簡単に紹介します。 Ansible を自由に利用できるようになるための基礎が幅広く記載されています。そのため、「インフラCI 実践ガイド」にもAnsibleが使われていますが、この内容を理解するのにも役立ちました。 また、これから新規にプレイブックを作るときの設計のポイントも記載されています。 Linuxサーバ向けだけでなく、Windowsやネットワーク機器向けの設定についても記載されており、これらを理解することでAnsibleのエコシステムや思想の理解が深まり様々な応用ができるようになります。
この記事はGWアドベントカレンダーの5日目の記事です。
Gitlabのリポジトリにsshで接続するときはOSのgitユーザを使います。 このユーザはGitlabのユーザすべてで共用します。 そのため、全利用者の公開鍵情報をgitユーザに紐付けて管理する必要があります。
これを実現する方法として、gitユーザのauthorized_keysに全ユーザ分の公開鍵を書いておく方法がありますが、sshアクセスの度にファイルを上からスキャンし、確認する必要があり効率が悪いです。 そこでユーザ名に応じた公開鍵を返すコマンドを用意することで余計な確認を減らすことで高速化することができる仕組みがあります。
以下にGitlabでの設定の仕方が書いてありますが、OpenSSHの提供するAuthorizedKeysCommandという設定を使うことで実現できます。この設定に、公開鍵を返すコマンドを指定します。
Fast lookup of authorized SSH keys in the database
この仕組みを使うと、gitユーザのauthorized_keysに公開鍵を記載する必要がありません。
この記事はGWアドベントカレンダーの4日目の記事です。
自宅のPCにIaC環境を構築中ですが、その環境について少し説明します。
1台の物理Linuxサーバ上にすべての環境を構築します。 仮想マシンはVagrant + Virtual Boxで構築します。 コンテナはDockerで構築します。 構築ツールとしてAnsibleを使います。 CI/CDを実現するためのツールとしてGitlab、Gitlab Runnerを使います。
GitlabとGitlab RunnerはAnsibleを使って、仮想マシンから作成します。 本番用とテスト用があり、テスト用の構築は本番用のGitlabのバックアップデータを使ってリストアすることで本番と同じデータを持つようにしています。
OSインストール後の各種設定類はAnsibleにまとめようと思っていますが、まだできていません。
Ansibleのプレイブック（Gitlabのパイプラインからの呼び出しや手動実行）によって、Vagrant経由で仮想マシンを作成することがあります。 しかし、AnsibleのInventory PluginとしてはVagrant用のものが正式にはありません。そのため、作成した仮想マシンに対してプレイブックを実行するためには何らかの方法を考える必要があります。 一つはInventory PluginもしくはScriptを作ること、もう一つは作成する仮想マシン情報をあらかじめインベントリファイルに記載しておくことが考えられます。 どちらの方法でも実現できそうですが、どのようにするか検討中です。
この記事はGWアドベントカレンダーの3日目の記事です。
GitlabとGitlab Runnerのバージョン情報がどこにあるのか書きます。 最新バージョンが出たかどうかを知るときや、アップデートするときのバージョンを指定したい場合に具体的なバージョンを知る必要があります。 実際には使用するリポジトリのバージョン名を知る必要がありますが、開発元のリリース情報は以下にあります。 なお、GitlabとGitlab Runnerのバージョンは対応していて、同じバージョンがリリースされるみたいです。
ここにあります。
ここにあります。
この記事はGWアドベントカレンダーの2日目の記事です。
1日目の記事で、CDの対象にすべきではありませんと述べましたが、ではどのようにデプロイすべきでしょうか。 CIサーバのデプロイ方法と言っても、単なるインストール手順のことではありません。CIサーバのライフサイクルを考えた上でデプロイ手順全体を指します。 なお、本記事ではGitlabを対象に述べます。
まずは本番用のCIサーバのライフサイクルについて考えます。
上記のように、一度インストールした後はアップデートを繰り返します。 アップデートの際に新バージョンのインスタンスを用意すれば良いように思うかもしれませんが、GitlabはDBにデータを持っていて、異なるバージョン間でのリストアはサポートされていません。 Gitlabの場合、バックアップの仕組みを持っていますが、リストアできるバージョンは、 バックアップ取得時と同じバージョンのみがサポートされています。 そのため、アップデート済みの新インスタンスを用意してもそこへ旧バージョンのデータをリストアすることはできません。
次にテスト用のCIサーバについて考えます。 テスト用のCIサーバは本番用と同じ操作を実施すべきなので、 テストの度に、本番用CIサーバと同じバージョンのものを再構築して動作を確認します。 ここで本番用CIサーバのバックアップデータを使ってテスト用CIサーバを構築するのがポイントです。 バックアップデータには各種プロジェクト情報やその設定値などが含まれています。これらのデータも本番用と同じものを使ってテストするのが理想的です。 したがって、テスト用CIサーバのライフサイクルは以下のようになります。
前述のように本番用CIサーバを一度構築した後は、アップデートの適用のみを実施するようなケースを考えた場合には、その都度、アップデートを適用する方法が考えられます。 この方法の場合には、初期構築手順とアップデート手順の二つがあれば良いことになります。 これらの手順を自動化しておくことで効率的にデプロイが実現できます。 ただし、故障発生などにより最初から構築する必要があった場合に、正しく構築できるかどうか懸念が残ります。
これを解決するのがImmutable Serverです。1日目の記事でCDの対象外と述べましたが、パイプライン中でのデプロイを行わないのであれば、テスト用CIサーバを本番用CIサーバとして利用するように切り替えることも可能です。 こうすることでImmutable ServerとしてCIサーバを扱うことができます。 しかし、このような運用をする場合には注意点があります。本番用のDBバックアップを取得してから本番用CIサーバに対し何か変更があると（管理対象プロジェクトのコミット等）、それが失われる可能性があります。 つまり、利用を制限した上でバックアップから切り替えまでを完了できる必要があります。 これは多くの場合は難しいと思います。
結局のところ、Immutable Serverとして扱うよりも、常にアップデートし続けるデプロイ方法の方が現実的ではないかと考えています。
明日はGitlabのバージョン情報について書く予定です。
この記事はGWアドベントカレンダーの1日目の記事です。
Infrastructure as Codeの考えでは、アプリケーションだけでなくインフラ部分（OSやミドルウェアなど）についてもCI/CDの対象として扱います。 この記事では、IaCに取り組もうと考えて最初に悩む（？）CIサーバ自身のCI/CDについて説明します。
CIサーバというのは、JenkinsやGitlabのようにコミットやプッシュを契機（trigger）に自動的にジョブを実行する機能を持つサーバのことです。 CIサーバ自身も様々な設定を持つ重要なサーバであり、管理対象です。
本記事では簡単のためにCIを自動構築と自動テストと定義します。また、CDを自動デプロイと定義します。 CI/CDのパイプラインとして自動にすべき部分や手動にすべき部分がありますが、本記事ではすべて自動で実施する場合としています。
IaCの文脈で、各サーバをImmutable Serverとして扱う場合を想定しています。 環境としてテスト環境と本番環境があります。CIサーバはテスト環境と本番環境の両方にアクセスできるので、便宜上CI環境に配置されているとします。 CIとして、テスト環境の再構築とテストを実施し、CDとして本番環境の再構築とテストを実施するものとします。
CIサーバをCDの対象とするということは、CI環境のCIサーバを再構築（破棄、作成）することになります。 CIサーバをImmutable Serverとして扱うと、パイプラインの途中でCIサーバの再構築が行われるため、必ず途中で中断することになりCDの対象とすることはできません。 CIサーバをいくつものコンポーネントに分けて、一部の機能のみCDの対象とすることはできると思います。
CIサーバはImmutable Serverではない（Mutable Server）として扱うとCIサーバをCDの対象とすることができます。しかし、パイプラインを実行中のCIサーバを変更するというのは複雑で、避けるべきと思います。
したがって、CIサーバはCDの対象とすべきではないと考えます。
CIの対象（以下、CI管理対象）というのは理想的にはすべてのサーバです。したがってCIサーバもCI管理対象とすべきと考えられます。
CIサーバのテスト用インスタンスを作成し、テストを実施することは有効です。ただし、テスト用インスタンスを使って実際のパイプラインを実行してはいけません。 実際のパイプラインはテスト用のCIサーバインスタンスの再構築を含んでいたり、テスト環境や本番環境のサーバ再構築を含んでいます。実行して良いのは接続確認のような環境に変更を加えない内容のものだけです。
CIサーバはCIの対象としますが、CDの対象外とします。 CIのパイプラインではテスト用インスタンスを作成し、自動テストを実行します。自動テストによってCIサーバの構築手順の妥当性を確認できます。
明日はCIサーバのデプロイ方法についての予定です。
インフラCI 実践ガイドを読みました。 以前読んだInfrastructure as Code（以下、IaC書籍）に対し、具体的な実装方法について説明しており今の自分に欲しい情報がたくさん得られて非常に満足しました。
本書はこれからインフラCIを始めようとする方向けの本です。インフラCIの具体的な実装の説明と、インフラCIの外側にある要素についても説明しています。 インフラCIの外側にある要素というのはシステムのデザインやリリースに関する制約やチームメンバのスキルなどです。インフラCIを導入し成功させるためにはインフラCIの外側にある要素も非常に重要です。
実際にインフラCIの環境を読者が実際に動かすことができるよう、演習環境としての構築方法とそれに必要な構成定義ファイルを提供しており、まさにこれから始める人にはうってつけの内容と思います。 また、インフラCIの技術的な側面だけでなく、インフラCIを実践するために必要な非技術的な要素についても随所で触れており、インフラCIをこれから導入しようとする場合のポイントについても理解ができるようになっています。 実際に最後の方の章では、技術的な観点というよりはインフラCIよりも広い範囲を考えた場合の導入方法についても述べられています。
IaC書籍は本書の中でも参照されており、より抽象的な概念の理解のためにIaC書籍を読んでおくと、本書の理解もより深まると思います。 実際に私もIaC書籍を読んでから本書を読みましたが、IaC書籍の内容ともリンクしてわかりやすかったです。
記述のスタイルとして、結果をまず述べてからその仕組みについて説明する形になっており、構成定義ファイルの中身についての説明が後回しになっていたり、省略されていたりします。そのため、具体的な構成定義ファイルの中身を見た方がイメージしやすい読者の場合には、ここに記載されている構成定義ファイルをPC上で見ながら本書を読むのも良いかと思います。
「しくみがわかるKubernetes」を読みました。
ほんとに仕組みがわかった気になりました。 これまでminikubeでhello worldをやっただけの経験でしたが、kubernetesがどういう仕組みになっているかの全体像を掴むことができました。
この本ではDockerなどのコンテナそのものについての説明はほとんどありません。
コンテナそのものを知らないとそもそもkubernetesの良さもわからないかもしれませんが、
この本で説明しているのはコンテナの管理をするkubernetesの仕組みです。 コンテナがどのような仕組みのものなのか、コンテナイメージはどのように作るのかというようなことは知らなくても読み進めることができると思います。
しくみを説明する本ですので、kubernetsの全体像としてどのようなコンポーネントで構成されているのかや、それぞれのコンポーネントの役割が説明されています。
また、Infrastructure as Codeの観点から、すべての定義をファイルに残すべきということも随所で述べてあります。
本文中に登場する定義ファイルはダウンロードできるようになっており、実際に試すことも可能です。
読者自身が実機で試す際も、細かな定義はすべてファイルに記載されているので、実際に打つコマンドはそれを適用するためのコマンドばかりです。
Kubernetesの環境を自分で構築するのは大変ですが、Azureで提供されているAKS（Azure Kebernetes Service）を使うことで簡単に利用を開始できます。
提供されているサンプルコードもAKS向けのものとなっているので、手軽に動作確認ができるようになっています。
この本ではKubernetesの主要コンポーネントの紹介と構成検討のポイントなどが述べられています。
含まれていないのは構築手順やオプションのコンポーネント等です。
例えば、ネットワークやストレージのコンポーネントについてはあまり説明がありません。
そのため、この本だけを見て自分でKubernetesを構築したいという方には向きませんが、クラウド上のマネージドサービスとしてKubernetesを使いたいという人には向いていると思います。
自分で環境を構築したいという人でも、この本を読むことで全体像がイメージできるようになりますので、具体的な検討へのステップとしては有効と思います。