rsyncは、帯域幅の消費を最小限に抑えるために効率的なアルゴリズムを使用する一般的なファイル同期ユーティリティです。 rsyncの一般的な役割の1つは、Webサイトビルドをリモートの本番サーバーにデプロイすることです。 rsyncの多様性とGitLabCIパイプラインによって提供される自動化を組み合わせる方法は次のとおりです。
GitLab CIは、いくつかのタイプのパイプラインエグゼキューターをサポートしています。これらは、ジョブが実行される環境を定義します。shell executorはデフォルトであり、ホストマシン上でベアメタルを実行します。これにより、パイプラインは、追加の構成なしで、ホストで使用可能な任意のコマンドを使用できます。最も人気のあるLinuxディストリビューションにはrsyncがインストールされた状態で出荷されるため、このアプローチは簡単に理解できます。
残念ながら、shell エグゼキュータは強力な分離を提供せず、時間の経過とともにホストの環境を汚染する可能性があります。より良い代替手段はdockerです executor。CIジョブごとに新しいDockerコンテナを起動します。すべてのジョブは、ホストに影響を与えないクリーンな環境で実行されます。
ここでの欠点は、Dockerベースイメージに通常rsyncが含まれていないことです。 またはssh 。 ubuntu:latestのような公式のOSイメージでさえ これらのコマンドなしで最小限のビルドとして出荷されます。これにより、依存関係とrsyncを追加するための少し複雑なパイプラインスクリプトが作成されます あなたのファイル。
パイプラインにrsyncを追加する方法は次のとおりです。続行する前に、DockerベースのGitLabRunnerが利用可能であることを確認してください。また、すぐに使用できるGitLabプロジェクトがあることを前提としています。
rsyncを使用してリモートSSHホストに接続する場合は、SSHキーペアが利用可能である必要があります。 ssh-keygen -t rsaを実行すると、公開鍵と秘密鍵を生成できます。 。接続するサーバーに公開鍵をコピーします。
次に、生成された秘密鍵をクリップボードにコピーします。
cat ~/.ssh/id_rsa | xclip -selection c
GitLabプロジェクトに移動し、左側のナビゲーションメニューの下部にある[設定]をクリックします。サブメニューの「CI/CD」項目をクリックします。結果のページの「変数」セクションまで下にスクロールします。
青い「変数の追加」ボタンをクリックします。 「キー」フィールドに新しい変数に名前を付けます。 SSH_PRIVATE_KEYを使用しています 。先頭の----BEGINを含む秘密鍵を「値」フィールドに貼り付けます 末尾の-----END 行。
キーをCI変数として追加すると、後でパイプラインでキーを参照できます。パイプラインが作成するコンテナのSSHエージェントに追加されます。
GitLab CIは、.gitlab-ci.ymlのコンテンツに基づいてジョブを実行します リポジトリ内のファイル。 GitLabはこのファイルを自動的に検出し、ブランチに変更をプッシュすると、GitLabが定義するパイプラインを実行します。
deploy:
stage: deploy
image: alpine:latest
script:
- rsync -atv --delete --progress ./ [email protected]:/var/www/html
この.gitlab-ci.yml rsyncを使用するジョブが含まれています 作業ディレクトリの内容を/var/www/htmlに同期します example.comで サーバ。 alpine:latestを使用します ビルド環境としてのDockerイメージ。 rsyncが原因で、パイプラインは現在失敗します アルパインの画像には含まれていません。
SSHとrsyncのインストール
アルパインは、依存関係がほとんどない軽量の画像であるため、この仕事に適したベースです。これにより、GitLabがジョブの開始時にイメージをプルし、パイプラインを高速化する間、ネットワークの使用が削減されます。 rsyncを機能させるには、SSHとrsyncをイメージに追加してから、SSHエージェントを起動し、前に生成した秘密鍵を登録します。
deploy:
stage: deploy
image: alpine:latest
before_script:
- apk update && apk add openssh-client rsync
- eval $(ssh-agent -s)
- echo "$SSH_PRIVATE_KEY" | ssh-add -
script:
- rsync -atv --delete --progress ./ [email protected]:/var/www/html
OpenSSHとrsyncは、Alpineのapkを使用してインストールされます パッケージマネージャー。 SSH認証エージェントが開始され、秘密鍵がssh-addを介して追加されます 。 GitLabは自動的にSSH_PRIVATE_KEYを挿入します プロジェクトの設定で定義した値を持つ環境変数。 GitLab変数画面で別のキーを使用した場合は、それに応じてパイプラインを調整してください。
SSHは、新しいリモートホストに初めて接続するときに、インタラクティブに確認を求めます。これは、これらのプロンプトを表示したり応答したりできないCI環境とは互換性がありません。
これに対処するには、2つのオプションを使用できます。厳密なホストキーチェックを無効にするか、サーバーを「既知の」ホストとして事前に登録します。
最初のオプションとして、パイプラインのbefore_scriptに次の行を追加します ：
- echo "Host *ntStrictHostKeyChecking no" >> ~/.ssh/config
これは機能しますが、潜在的なセキュリティリスクです。攻撃者がサーバーのドメインまたはIPを制御した場合でも、警告は表示されません。ホストキーチェックを使用すると、リモートのIDが期待どおりであることを確認できます。
パイプラインの外部にある自分のマシンでリモートに接続することにより、リモートを既知のホストとして非対話的に追加できます。 ~/.ssh/known_hostsを調べます ファイルを作成し、リモートのIPまたはホスト名を含む行を見つけます。この行をコピーし、前の手順を使用して新しいGitLabCI変数を追加します。この変数にSSH_HOST_KEYという名前を付けます 。
次に、before_scriptを更新します 次の行のセクション：
- echo "$SSH_HOST_KEY" > ~/.ssh/known_hosts
これで、確認のプロンプトを受信せずにサーバーに接続できるようになります。コードをGitLabリポジトリにプッシュし、パイプラインが完了するのを監視します。
このパイプラインは、Docker化された環境でSSHとrsyncを開始する方法の簡単な例です。パイプライン間で再利用できるDockerイメージを構築する専用のビルドステージに準備手順をラップすることで、システムをさらに改善する機会があります。
.gitlab-ci.yml また、変数をより多く使用することでメリットが得られます。リモートサーバーのホスト名を抽象化する（example.com ）、ディレクトリ（/var/www/html ）、およびユーザー（user ）をGitLab CI変数に組み込むと、ファイルをクリーンに保ち、カジュアルなリポジトリブラウザーが環境の詳細を表示するのを防ぎ、パイプラインファイルを編集せずに構成値を変更できるようになります。
GitLab CIパイプラインでrsyncを使用するには、必要な依存関係を持つビルド環境を形成するために、少し手動でセットアップする必要があります。 SSH秘密鍵を手動で挿入し、リモートサーバーを既知のホストとして登録する必要があります。
SSHとrsyncを人気のあるベースイメージの上にロールバックするコミュニティDockerイメージが利用可能ですが、これらは最終的にビルドの制御を弱めます。必ずしも信頼できないイメージでパイプラインのサプライチェーンを拡張しています。 OSベースのイメージから始めて、必要なものを追加することで、ビルドに自信を持つことができます。