みなさんこんにちは。
完全なCIを必要とするタスクは多くありません。 しばらくの間、JenkinsをCIサービスとして使用しました。 そこにはすべてが明らかであり、設定が簡単で柔軟性があり、多くのプラグインがありますが、2、3回、弱いマシンでエージェントのOOMキラーに遭遇し、Gitlab CIをCIサービスとして検討することにしました。前回の記事で、彼らはそのような質問をしました。
GitLab-CEをインストールする
Omnibusパッケージがあるため 、ここではすべてが非常に簡単です。
必要なパッケージをインストールして実行します。
sudo yum install curl openssh-server openssh-clients postfix cronie sudo service postfix start sudo chkconfig postfix on
Gitlab-CEをインストールします。
curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash sudo yum install gitlab-ce
Gitlab-CEを構成して起動します。
sudo gitlab-ctl reconfigure
ランナーのインストール
GitLab Runnerは、特別な.gitlab-ci.ymlファイルから命令を実際に実行するエージェントです。
Jenkinsとは異なり、ヒットラボランナーはGoで記述されているため、非常に小さくて高速です。 また、ローカル、ドッカーコンテナ、異なるクラウド、またはサーバーへのssh接続を介して、まったく異なる方法でタスクを起動できます。 いつものように、ドキュメントの詳細
最後の記事へのコメントの誰かが、Gitlabでansibleプレイブックをテストすることを検討し、それを取るように頼みました。
テスト環境と実稼働環境のIDを確認するために、Dockerを使用します。
Dockerでランナーを実行するには、最初にdockerをインストールする必要があります。
curl -sSL https://get.docker.com/ | sh
ランナーのインストール
# Debian/Ubuntu curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash # RHEL/CentOS curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash
# Debian/Ubuntu sudo apt-get install gitlab-ci-multi-runner # RHEL/CentOS sudo yum install gitlab-ci-multi-runner
ランナーを構成してCIサービスに接続する：
sudo gitlab-ci-multi-runner register Please enter the gitlab-ci coordinator URL (eg https://gitlab.com/ci ) http://domain.example.com/ci Please enter the gitlab-ci token for this runner bQ0nvkVJACDUrvQ9ttqx Please enter the gitlab-ci description for this runner my-runner INFO[0034] fcf5c619 Registering runner... succeeded Please enter the executor: shell, docker, docker-ssh, ssh? docker Please enter the Docker image (eg. ruby:2.1): centos:7 INFO[0037] Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!
GitlabのURLを指定し、認証用のトークンを登録します。
dockerの場合、ランナーの名前、ジョブを開始する方法も指定する必要があります-ランナーを実行するイメージを指定します。
ランナーの構成は、url example.com/groupname/projectname/runnersで示されます
ここで、ランナーの名前と、このランナーでプロジェクトをアセンブルするラベルを編集できます。 たとえば、プロジェクトをさまざまな段階でテストする必要があります。最初にシェルで、次にそれをdockerコンテナーにパックし、sshでどこかでロールします。 これについては後で詳しく説明します。
そこから、マスターURLとトークンを取得して、「マスター」のランナーを承認する必要があります。
打ち上げ
sudo gitlab-ci-multi-runner start
その後、プロジェクトランナーのリストに表示されます。
Container Registryのインストール
少し前まで、 Container Registryは Gitlab に統合されていました。
GitLab Container Registryは、Dockerイメージを保存するための安全なプライベートリポジトリです。
/etc/gitlab/gitlab.rbセクションのコンテナレジストリ設定を確認しています
registry_external_url 'https://domain.example.com' # Settings used by GitLab application gitlab_rails['registry_enabled'] = true gitlab_rails['registry_host'] = "domain.example.com" gitlab_rails['registry_port'] = "5000" gitlab_rails['registry_api_url'] = "http://localhost:5000" gitlab_rails['registry_key_path'] = "/var/opt/gitlab/gitlab-rails/certificate.key" gitlab_rails['registry_path'] = "/var/opt/gitlab/gitlab-rails/shared/registry" # gitlab_rails['registry_issuer'] = "omnibus-gitlab-issuer" # Settings used by Registry application registry['enable'] = true registry['username'] = "registry" registry['group'] = "registry" # registry['uid'] = nil # registry['gid'] = nil registry['dir'] = "/var/opt/gitlab/registry" registry['log_directory'] = "/var/log/gitlab/registry" registry['log_level'] = "info" registry['rootcertbundle'] = "/var/opt/gitlab/registry/gitlab-registry.crt" registry['storage_delete_enabled'] = true
必要なものの：
gitlab_rails ['registry_enabled'] = trueおよびレジストリ['enable'] = trueを設定する必要があります
registry_external_urlで、リポジトリが配置されるサーバーのドメイン名を指定します。
次の設定も見つける必要があります。
registry_nginx['ssl_certificate'] = "/path/to/certificate.pem" registry_nginx['ssl_certificate_key'] = "/path/to/certificate.key"
そして、証明書への正しいパスを指定します。
自己署名証明書が使用される場合、画像のすべての作業が行われるdocker- daemon側で--insecure-registryオプションを設定する必要があります。そうしないと、ログインしようとするとエラーが発生します（ランナーも懸念します）。
Debianの場合： /etc/systemd/system/multi-user.target.wants/docker.service
[Unit] Description=Docker Application Container Engine Documentation=https://docs.docker.com After=network.target docker.socket Requires=docker.socket [Service] Type=notify ExecStart=/usr/bin/docker daemon -H fd:// --insecure-registry domain.example.com MountFlags=slave LimitNOFILE=1048576 LimitNPROC=1048576 LimitCORE=infinity TimeoutStartSec=0 [Install] WantedBy=multi-user.target
（はい、ポートを指定する必要はありません。レジストリ用のAPIがあります-ローカルホストでハングアップします：5000と、画像の承認と追加作業が行われるフロント。ローカルホストからAPIを転送する方法を探しています:)）
変更を適用する
systemctl daemon-reload
systemctl restart docker
gitlabアカウントでログインしてみてください
docker login domain.example.com Username: root Password: Email: admin@example.com WARNING: login credentials saved in /root/.docker/config.json Login Succeeded
さて、これで何かをし、最初のパイプラインを構築し、プロジェクトがどのように組み立てられるかを見てみましょう。
CIセットアップ
ansibleプレイブックのテストを始めましょう：
詳細については触れませんが、serverspecとtest-kitchenについては説明しません。これらについては、前回の投稿ですでに説明しました。
まず、テスト用の環境で単純なイメージを組み立てます。 Dry runとansible-lintを回避しましょう 。
vim dockerfile
FROM centos:7 RUN yum -y update && yum -y install epel-release \ && yum -y install ansible python-pip RUN pip install ansible-lint # Default command CMD ["/bin/bash"]
さて、画像をまとめましょう
docker build -t centos:7 .
そして、レジストリにプッシュ
docker tag centos:7 domain.example.com/<groupname>/<projectname> docker push domain.example.com/<groupname>/<projectname>
次に、パイプラインについて説明します
プロジェクトのルートで、.gitlab-ci.ymlファイルを作成し（YAMLを繰り返します）、プロジェクトをビルドする手順を説明します。
image: domain.example.com/root/my-repo stages: - test - deploy test_job: stage: test script: - ansible-lint playbook.yml - ansible-playbook --check playbook.yml tags: - ansible deploy_job: stage: deploy script: - ansible-playbook playbook.yml tags: - ansible
ここでは、プロジェクトアセンブリの段階を示します。 テスト段階では、構文エラーについてリントスルーし、ドライモードでAnsibleを実行します。つまり、ホストに変更を適用せずに、単に表示するだけです。 プレイブックの再生中に突然何かが壊れた場合、ホスト構成が変更される前にこれについて知ることができます。
それに対応して、プレイブックのどこかにスペースを追加しようとすると、設定は適用されず、lintはテスト段階でエラーとクラッシュを報告します。これは、gitlab Webインターフェイスで直接コミットした後に見つけることができます。
.Gitlab-ci.ymlに は 、プロジェクトライフステージのすべてのケースに対して多くの異なるオプションがあります 。 残念ながら、ある夜にすべてを知ることはできませんでした。
ご覧のとおり、Gitlabは他のCIサービスよりも悪くはなく、肯定的で便利なインターフェイスを備えていますが、テストスクリプトの作成と展開に関する機能があります。
ご清聴ありがとうございました。 良い自動化！