Ubuntu 20.04上のGitLabセルフマネージドインスタンスでDockerイメージリポジトリをホストし、Dockerイメージをビルドする方法

コンテナ化技術は、クラウド環境でアプリケーションをパッケージ化してデプロイするための最も受け入れられている方法として、ソフトウェア開発技術の分野で大きく進歩しました。これは、継続的インテグレーション（CI）および継続的デプロイ（CD）の必要性によって不可欠となったものであり、これらは次の定義的な側面です：DevOps。ソフトウェア開発者やエンジニアは、ソフトウェアアーキテクチャのCI/CDの側面を実現するためにコンテナを利用しています。コンテナとは、本質的には完全にパッケージ化された、ポータブルで自己依存型のコンピューティングプラットフォームです。ウェブ上にはいくつかのコンテナプラットフォームが存在しますが、Dockerが最も一般的です。

Dockerはオープンソースのコンテナプラットフォームであり、開発を効率的かつ予測可能にします。Dockerは、以下で利用可能なパブリックなDockerイメージリポジトリを提供しています：Docker Hub。ここには、プルして使用できる最も一般的な実装のための多くのオープンソースDockerイメージが含まれています。パブリックリポジトリであるため、独自のDockerイメージを自由に追加して一般に共有することもできます。ただし、プライベート/独自のコードがある場合は、プライベートイメージリポジトリに料金を支払うか、独自のイメージリポジトリサービスを構築する必要がある場合があります。ここでGitLabの出番となります。

GitLabは、単なるバージョン管理ツールにとどまらない、ウェブベースのGitリポジトリです。継続的インテグレーションとデプロイ、課題追跡、DockerイメージレジストリなどのためのDevOpsツールを提供します。GitLab Community Edition (CE)、GitLab Enterprise Edition (EE)、およびGitLab SaaSの3つのオプションを提供しています。GitLab CEとGitLab EEは、GitLabインスタンスをご自身でダウンロード、インストール、管理できるセルフマネージドソリューションです。GitLab SaaSはGitLab社によってホストされているため、使用するために何かをインストールすることを心配する必要はありません。

以前のチュートリアルでは、CloudSigmaサーバー上にGitLabインスタンスをセットアップし、独自のGitリポジトリをホストする方法を紹介しました。また、GitLab Runnerを使用した継続的インテグレーションパイプラインを実装して、新しいコミットがあるたびにテストを自動的にビルドして実行する方法も紹介しました。言及したチュートリアルをまだお読みでない場合は、このチュートリアルの基礎となるため、ぜひご一読ください。

このチュートリアルでは、シンプルなDockerイメージをビルドし、GitLabのセルフホストインスタンス（Community EditionまたはEnterprise Editionのどちらを使用していても、手順の流れは同じです）でホストする方法を説明します。–手順の流れは同じです）。

前提条件

このチュートリアルのすべてのステップに従うには、以下で説明するように、GitLab CI runnerとセルフホストのGitLab serverが用意されていることを確認してください。

1. セキュアなGitLabサーバー

これを使用して、ソースコードの保存、CI/CDタスクの実行、およびDockerイメージレジストリのホストを行います。セルフマネージドGitLabインスタンスをインストールするためにGitLabが推奨する、少なくとも2 CPUコアと4GBのRAMを備えたサーバーが必要です。また、サーバーを保護するためにLet’s EncryptからのSSL証明書を取得するために使用するため、サーバーを指す登録済みのドメイン名も必要です。以下は、GitLabセルフホストインスタンスをセットアップするために参照できるリンクです。

• お好みのドメイン名登録業者でドメイン名を登録し、point it to CloudSigma.
• 次のチュートリアルに従って、initial Ubuntu server setup, add a non-root user、およびenable Ubuntu’s UFW firewall.
• を行います。最後に、このtutorial to install and configure a self-hosted GitLab instance.

2. GitLab CI Runner

テストケースに対して自動化されたジョブを実行するには、GitLab CI Runnerが必要です。また、how to set up GitLab Continuous Integration pipelines on Ubuntu 20.04に関するチュートリアルでは、GitLab CIサーバーの概要を説明し、ジョブをトリガーする方法を示しています。まだ設定していない場合は、チュートリアルの手順に従ってGitLab CI Runnerサービスをセットアップしてください。このチュートリアルには、テストケースを含むNode.js demo app（テストケース付き）が含まれており、– このチュートリアルではこれを使用します。

それでは、始めましょう！

ステップ1：特権GitLab CI Runnerの設定

GitLab CI Runnerのセットアップ方法に関するチュートリアルでは、次のコマンドを使用してGitLab Runnerを設定しました：sudo gitlab-runner register コマンドを使用することで、必要なパラメータをインタラクティブに追加することができました。これは、隔離されたDockerコンテナ内でビルドやテストを実行するという以前のユースケースでは機能しましたが、Dockerイメージのビルドには対応できない可能性があります。Dockerイメージをビルドするには、ランナーがDockerサービスへのフルアクセス権を持っている必要があります。この構成は、公式の docker-in-docker イメージを使用してジョブを実行することで実現できます。このような構成では、ランナーに privileged 実行モードを付与する必要があります。

While granting the privileged 実行モードを付与することは、Dockerイメージをビルドするために必要ですが、セキュリティ上の問題が伴います。これは、コンテナのセキュリティ上のメリットを排除することになるためです。他のDockerランナーは安全だと思うかもしれませんが、それらにも説明されているように同様の問題があります 公式のDockerドキュメントで.

特権実行モードを持つ別のランナーを作成します。上述のセキュリティ上の影響があるため、これはプロジェクト固有のランナーになります。このランナーは、Node Pipeline プロジェクト（チュートリアル「how to set up continuous CI pipelines with GitLab」で作成したもの）からジョブを受け入れます。.

最初に行うべきことは、Shared Runners がプロジェクトで無効になっていることを確認することです。Node Pipeline プロジェクトのプロジェクトページから、左下のメニューにある Settings をクリックし、サブメニューで CI/CD を選択します：

Find the Expand ボタンを Runners セクションで見つけ、クリックして利用可能なランナーの詳細を表示します：

スイッチをクリックして、このプロジェクトの Disable Shared Runners にします。前のセクションでプロジェクト固有のランナーを追加していた場合は、それも無効にしてください。このプロジェクトのジョブを実行するために、privileged なプロジェクト固有のランナーを追加します。これにより、GitLabが特権実行モードで登録されていないランナーにランダムにジョブを割り当てた場合に、ビルドエラーが発生するのを防ぐことができます。上のスクリーンショットの Specific runners タブの下に、プロジェクトの registration token が表示されているはずです。以下で使用するため、メモしておいてください。

注意: プロジェクト固有のランナーは、Admin panel > Runners セクションから他のプロジェクトに割り当てることもできます。ランナーのリストからランナーを選択すると、ランナーの設定ページに移動します。下にスクロールして、Restrict projects for this runner:

ターミナルを起動する時間です。もし、チュートリアル「how to set up GitLab Continuous Integration Pipelines on Ubuntu 20.04」の手順をまだ実行していない場合は、このチュートリアルを一旦休止して、その手順に従い、GitLab CI ランナーサービスを備えたサーバーを用意してください。すでに完了している場合は、次のステップのために GitLab CI runner server に sudo user でSSH接続してください。

特権プロジェクト固有のランナーをセットアップするには、ターミナルで次のコマンドを入力します。その際、ドメイン名と上記でコピーした登録トークンを置き換えてください：

この出力は、登録が成功したことを示しています：

GitLabインスタンスがランナーを認識したことを確認するには、ブラウザに戻り、Settings > CI/CD ページを更新します。Runners セクションを展開すると、Specific Runners:

必要に応じて、Admin Panel に移動することもできます（上部バーの Menu ボタンをクリックして Admin),。その後、メニューオプションで Runners を選択します：

お使いの GitLab instance, に接続されている、共有ランナーとプロジェクト固有のランナーの両方の利用可能なすべてのランナーが表示されたページが表示されるはずです：

ここまでの手順で、Dockerイメージをビルドできるランナーのセットアップが正常に完了しました。

ステップ 2: GitLabのDockerレジストリの構成

一部の重要なワークフローでは、外部サービスからの独立性が必要です。そこで役立つのが、GitLabのセルフマネージド型Docker Registryです。安全であるだけでなく、ニーズに合わせてジョブやパイプラインを柔軟に調整できます。設定を行うには、Docker Registryを設定するために、GitLabの設定ファイルを変更します。まず、GitLabインスタンスにSSHで接続し、次のコマンドでファイルを開きます：

以下が表示されるまでスクロールします：Container Registry Settings:

次の行のコメントアウトを解除します：registry_external_url。そして、GitLabインスタンスのドメイン名に設定し、末尾にポート番号8888を指定します：

次に、以下の行を追加して、レジストリがLet's Encrypt証明書を見つける場所を指定する必要があります。実際のGitLabインスタンスのドメイン名に変更することを忘れないでください：

完了したら、ファイルを保存して閉じます。ターミナルで次のコマンドを入力して、GitLabを再構成（reconfigure）します：

次に、コマンドの実行が完了するまで数秒待ちます。成功すると、以下のような出力が表示されます：

次に、ファイアウォール（ufw）が、次のコマンドを使用して割り当てたレジストリポートへのトラフィックを許可していることを確認する必要があります：

次に、Docker Registryが動作していることをテストするために、Dockerがインストールされている別のマシンからdocker loginコマンドを使用してログインします。ローカル環境にDockerをセットアップしていない場合は、すでにDockerがインストールされているGitLab CIランナーサーバーにSSH接続できます。次に、もちろんGitLabインスタンスのドメイン名を指定して、以下のコマンドを実行します：

出力には、次のようにLogin Succeededメッセージが表示されます：

これは、レジストリが正常に構成され、動作していることを意味します。イメージを作成すると、それらはGitLabサーバーのファイルシステムにローカルに保存されます。これはプライベートな企業レジストリとしては問題ありません。ただし、レジストリを一般に公開する予定がある場合は、より大きなストレージが必要になる可能性があります。幸いなことに、GitLabはストレージバケットに接続するオプションを提供しています。詳細については、公式のGitLab container registry docsを参照して、GitLabインスタンスのストレージバケットを構成する方法を確認してください。

ステップ 3: gitlab-ci.ymlファイルの変更とDockerイメージのビルド

このステップに進むには、GitLabインスタンスにNode Pipelineプロジェクトが必要です。以下はGitLab上でのプロジェクトの表示です：

以前、gitlab-ci.ymlについて、アプリケーションのビルド方法や自動テストの実行方法を知るために、トリガーされたときにGitLab CIランナーが読み取るファイルとして説明しました。Dockerイメージをビルドするための指示を追加するために、このファイルを変更する必要があります。このファイルは、GitLabのインターフェース内で直接編集することもできます。また、ローカルマシンにクローンしてお気に入りのエディタで編集し、コミットしてGitLabにプッシュ（git push）することもできます。簡潔にするため、ここではGitLabインスタンスを使用します。

ファイルをクリックして開き、次に編集ボタンをクリックします：

これにより、ファイルが編集可能な状態で開きます。ファイルの内容をすべて削除し、次のコードを追加します：

上記のコードスニペットを追加する際は、ハイライトされた部分を実際の詳細情報に更新することを忘れないでください。完了したら、Commit changes ボタンを押して変更を保存します。GitLabの外部で作業していた場合は、変更をコミットしてプッシュしてください。

追加したコードが .gitlab-ci.yml ファイルで何を行っているかを理解しましょう。最初の行は、GitLabに公式の Docker-in-Dockerイメージ を使用するように指示し、それをdocker-in-dockerサービス（docker:dind）にアタッチします。次に、build, test、および release のステージを定義します。build ステージは、Dockerfile の指示に従ってイメージをビルドし、前のステップでセットアップした Docker Registry にアップロードします。

When the build ステージが成功すると、test ステージがイメージをダウンロードし、コンテナとして実行して、npm test コマンドを実行して内部で自動テストを行います。もし test ステージが成功すると、release ステージが引き継ぎます。リリースステージでは、イメージがダウンロードされ、node_pipeline:latest としてタグ付けされます。その後、レジストリにプッシュバックされます。

これはデモプロジェクト用の基本的な設定にすぎません。実際のプロジェクトでは、たとえば staging, production などの他のステージを設定することもできます。編集後にファイルを保存すると、パイプラインがトリガーされ、ジョブの実行が開始されます。Node Pipeline ページに戻ります。ジョブが現在実行中であることが確認できるはずです：

Click on the CI インジケーターアイコンをクリックして、ジョブのさまざまなステージを表示します：

上のスクリーンショットでわかるように、緑色のチェックマークアイコンが示す通り、すべてのステージが成功しました。各ステージをクリックして、ジョブの出力を表示できます：

左側のメニューで、Packages & Registries をクリックし、Container Registry:

を選択します。これにより、選択したプロジェクトで利用可能なDockerイメージを一覧表示するページが表示されます。ビルドしてリリースしたイメージが、割り当てられたタグとともにリストに表示されるはずです。:

クリックして、イメージのさまざまなタグを表示します：

ローカル環境にDockerがインストールされている場合は、イメージをプルして期待通りに動作するかテストできます。イメージタグ名の横にある Copy アイコンをクリックします。これにより、docker pull コマンドで使用できる完全なイメージ名がクリップボードにコピーされます：

上記のコマンドはイメージをプルし、コンテナ内で実行します：

アプリは現在、次のポートで提供されています：8090. ブラウザを開いて、your-IP-address:8090 にアクセスすると、ページが表示されるはずです：

ブラウザにこのようなページが表示されていれば、Dockerイメージのビルドと、プライベートな Docker Registry での共有に成功しています。今後、master ブランチに変更を加えると、.gitlab-ci.yml ファイルで定義されたステージが実行され、それらが成功すると、タグ latest が付いた新しいDockerイメージが再ビルドされ、レジストリにプッシュされます。

まとめ

このプロジェクトでは、privileged GitLabランナーをGitLabのセルフマネージドインスタンスに追加して、Dockerイメージをビルドできるようにする方法を学びました。また、イメージをホストするためのプライベートなDockerイメージレジストリも設定しました。Node pipeline プロジェクトを使用することで、セットアップのすべてのコンポーネントをテストし、期待通りに接続および通信していることを確認できました。イメージがレジストリで利用可能になると、それをプルしてコンテナ内で実行されていることを確認できました。

これは入門用のチュートリアルであり、基礎を構築するためのものです。詳細については、公式の GitLabの詳細について学ぶためのGitLabドキュメント を参照してください。このリンクからは、GitLab Container Registry.

に関する情報を得ることができます。Dockerを活用するためのさらなるリソースについては、当ブログ:

• Dockerコンテナ間でのデータ共有
• Ubuntu 18.04でのプライベートDockerレジストリのセットアップ
• Dockerコンテナとホスト間でのデータ共有方法
• Dockerリソース（イメージ、コンテナ、ボリューム）のクリーンアップ

Happy Computing!