Hnoss

Hnoss

GitLabのグループ機能はとんでもないツールだった。
カレンダー

文書タグ

フノス(訳者)(208) IT(184) 解説記事(140) マニュアル(78) GitLab CI(58) オープンソース(50) Linux(38) GitLab(33) メディア(33) コンテナ(28) ウェブ制作(25) DTM(19) HTML5(19) Libre Music(18) おすすめ オープンソース・ソフトウェア(18) 百科事典(14) プラグイン(13) 文化(12) ソフトウェア(11) セキュリティ(11) 録音(11) ミキシング(11) MIDI(10) 西アジア/中東(10) 料理(9) ジョージア(9) グルジア(9) 東ヨーロッパ(9) シーケンス(8) 芸能(8) 音楽編集(8) コマンド(8) 音楽(7) 経済(7) マスタリング(7) Raspberry Pi(6) 業務効率化(6) Google(5) WordPress(5) アプリ(5) JACK(5) マイクロサービス(5) 北米(4) Windows(4) Android(4) ワークフロー(4) 映像制作(4) ハンドブック(4) GNU(4) 欧州(4) 音楽プレーヤー(4) Ubuntu(4) Python(3) アニメ(3) ホームオートメーション(3) アニメーション(3) IoT(3) Ardour(3) 社会(3) Java(3) ソーシャルメディア(3) DAW(3) 法律(3) スマホ(2) 牛(2) 歴史(2) ニュース(2) GNOME3(2) iOS(2) PlayStation(2) 仮想通貨(2) 古代エジプト(2) マーケティング(2) 有角神(2) エジプト(2) ALSA(2) OS X(2) ERPシステム(2) 電子ブック(2) トヨタ(2) バト(2) Krita(2) 電子書籍(2) ウィッカ(2) GPL(2) ERP(2) オカルト(2) Twitter(2) ロスレス音源(2) BountySource(2) 元ネタ(1) ケルヌンノス(1) ナイジェリア(1) 日記(1) 聖書(1) 任天堂 DS(1) 教育(1) bi-modal IT(1) 魔女宗(1) アクティブSETI(1) バイノーラル(1) Papagayo(1) 写真(1) 意味(1) コシディウス(1) インド(1) ユーコン(1) ヤーウェ(1) CD(1) タブレット(1) 学校(1) 日本(1) 羊(1) ベルゼブブ(1) デジタルサイネージ(1) VR(1) アップストリーム・パッケージング(1) 画像(1) 由来(1) グンデストルップの大釜(1) カナン(1) カナダ(1) サウンドフォント(1) 詩篇(1) チップチューン(1) バ・ネブ・デデト(1) コットン・マザー(1) クラウドキャスティング(1) VST(1) ポータブルソフトウェア(1) エリファス・レヴィ(1) マサチューセッツ(1) 考古学(1) 申命記(1) クヌム(1) 魔女裁判(1) オンデマンド(1) リーナス・トーバルズ(1) バフォメット(1) UNIX(1) 黙示録(1) スタジオジブリ(1) アモン(1) セイラム魔女裁判(1) ねじ巻きラジオ(1) 3D(1) 政治(1) イボ人(1) 国際(1) クリエイティブ・コモンズ(1) amazon(1) キリスト教(1) レビ記(1) Synfig(1) 独占(1) アマナイ(1) 広告(1) KXStudio(1) EU(1) イケンガ(1) 国際公文書館会議(1) マイナビ(1) 募金(1) ユダヤ教(1) ウルガタ聖書(1) 科学技術(1) 出エジプト記(1) 観光案内(1) 絵文字(1) サンフランシスコ(1) パキスタン(1) リクルート(1) ハトホル(1) パン(1) 地方(1) Blender(1) 羊神(1) ギリシャ(1) 高速道路情報無線(1) ツイッター(1) Youtube(1) 中南米(1) モヘンジョ=ダロ(1) CC(1) 声明(1) 悪魔(1) ラジオ(1) アレクサンドロス大王(1) ローマ(1) ポッドキャスト(1) ゲーム(1) パシュパティ(1) 1Password(1) アピス(1) 宗教(1) テレビ(1) OpenToonz(1) 電子教材(1) 船乗りの柱(1) シリア(1) GPS(1) アフリカ(1) リグ・ヴェーダ(1) F-Droid(1) ムネヴィス(1) ネオペイガニズム(1) コミュニティ放送(1) アンビソニック(1)
リファレンス

first-time visitors
user guide
謝辞

「みんなの翻訳」は情報通信研究機構言語翻訳グループ東京大学図書館情報学研究室による共同プロジェクトであり、三省堂国立情報学研究所連想情報学研究開発センターが開発に協力しています。三省堂には「グランドコンサイス英和辞典(36万項目収録)」の使用を許可していただきました。

連携研究グループはこちらをご覧ください。

「みんなの翻訳」を使っている翻訳グループについてはこちらをご覧ください。

バナー

logo

ポスター

poster

フライヤー

poster poster
Mozilla Firefox ブラウザ無料ダウンロード
本サイトはブラウザ「Mozilla Firefox」推奨です。
Firefox3で動作確認しています。

Valid XHTML 1.0 Transitional


GitLab Documentation>GitLab Continuous Integration (GitLab CI)>Dockerをインテグレーションに活用する>Dockerイメージを使う

>Docker Runnerを登録する
>「image」とは
>「service」とは
  >サービスをjobと連携させる方法
  >サービス・コンテナへのアクセス
>「.gitlab-ci.yml」から「image」と「services」を決定する
>Docker拡張設定オプション(原:Extended Docker configuration options)
  >「image」で使える設定オプション
  >「services」で使える設定オプション
  >同じイメージ内で様々なサービスコンテナを展開する
  >サービスコンテナ向けにコマンドを設定する
  >イメージのエントリーポイントを優先させる
>「config.toml」ファイルで「image」と「services」を定義する方法
>プライベート・コンテナレジストリから「image」を定義する
>サービスをより細かく設定する
  >PostgreSQLサービス設定例
  >MySQLサービス設定例
>Dockerインテグレーションの作動順序
>jobをローカル環境でデバッグする方法

 GitLab CIは、GitLab ランナーと連携して、Dockerエンジンをアプリケーションのテストやビルドの道具に変身させます。また、様々なアプリケーションに対応できる実用性も兼ね備えています。

 Dockerとは、オープンソースのコンテナ作成ツールです。
 「コンテナ」という、単一のLinuxとほぼ同じ動きを取る隔離環境を作ることができます。アプリケーションを運営する上でとても便利なアイテムです。
  Docker Hubというページには、既にビルドが完了しているイメージが大量に掲載されています。これらをアプリケーションのテストやビルドに使うことができます。

 DockerをGitLab CIと併用した場合、CIが抱えるそれぞれのjobは、コードを記述するときに使用しているものとはまた別の定義済みコンテナによって実行されます。

 CIは「.gitlab-ci.yml」というファイルで設定します。セットアップ自体は簡単です。
 これにより設定されたCIコンテナは、10年ほど前なら我々が手作業で構築していたはずの「ビルド環境」というものを、ほとんど完璧に再現します。
 設定によっては、ビルドを終えたアプリケーションを、そのままワークステーションに提出することが可能です。

 皆さんは全てのコマンドを試験するときなどに、あらかじめ細工しておいたシェルを用いて、その合否を確かめていたことでしょう。ですが、そこを専用のCIサーバーに集約することで、様々な工程を一本化できます。

 Docker Runnerを登録する

 GitLabランナーをDockerで運用する場合、dockerエグゼキューターにランナーを登録する必要があります。

 たとえば、簡単な例でいけば以下のような設定をします。

======================
sudo gitlab-runner register \
  --url "https://gitlab.example.com/" \
  --registration-token "PROJECT_REGISTRATION_TOKEN" \
  --description "docker-ruby-2.1" \
  --executor "docker" \
  --docker-image ruby:2.1 \
  --docker-postgres latest \
  --docker-mysql latest
======================
 (訳者より:¥はバックスラッシュの誤変換です。)

 この設定で登録できるランナーは、「ruby:2.1」Dockerイメージです。
 このDockerでは2つのサービスを抱えております。1つめは、「postgres:latest」もう1つが「mysql:latest」で、ここに書かれたということは、どちらもビルドプロセスでアクセス可能な状態になり、プロセスを完成させるのに欠かせない役割を担っているということです。

 「image」とは

 Dockerを使っていく上で欠かせないキーワードが「image」です。これはどのような種類のDockerコンテナを使っていくかを定義するパラメータです。
 とりわけ今回は、CIの設定をしていますので、定義されたイメージは、CIタスクを実行するのに使われます。

 デフォルトでは、Docker Hubから引いてきたイメージ以外は使われないように設定されていますが、
gitlab-runner/config.toml」というファイルのDocker pull policyを変更することで、ローカル環境にあるDockerイメージなどが使えるようになります。

 Docker Hubの詳しい利用方法については、Docker Fundamentalsというガイダンスに従ってください。

 「service」とは

 「service」は、Dockerイメージを定義するもう1つのキーワードです。ここで定義されたサービスには、「image」で定義されたDockerイメージとランナーで実行されるjobとの間をリンクする役割があります。
 ここで定義されたサービス用Dockerイメージは、ビルドの際になって初めてアクセスが開始されます。

 「service」イメージはどのアプリケーションでも運用可能ですが、たいてい、ビルドにデータベースコンテナ(mysqlなど)が必要とされる時に使われます。
 CIでjobを達成するために、どうしてもすぐさま動かせるコンテナイメージが必要なことがあります。プロジェクトをビルドするたびにインストールしていた「mysql」などの追加コンテナは、ここに定義しましょう。

 よく誤解されがちですが、ここに定義できるのはデータベースだけではありあません。他にも様々なサービスを追加することができます。
 設定は「.gitlab-ci.yml」あるいは「config.toml」にしてください。 Docker Hub /ローカル環境のコンテナイメージを指定するだけで、サービスコンテナが利用できるようになります。

 こちらの 『CIサービス設定例』というページでは、ビルド環境にサービスコンテナを設置する具体的な方法が紹介されています。

 サービスをjobと連携させる方法

 コンテナをリンクさせる方法については、Docker公式によるLinking containers togetherをお読みいただいた方が良ろしいでしょう。

 かいつまんでいえば、「mysql」をサービスとして追加した場合、Dockerイメージはjobとリンクしたサービスコンテナを使うようになるという話です。

 この場合「MySQL」コンテナがjobとリンクするようになります。デフォルトでのホスト名は「mysql」となっており、これがイメージによるサービスコンテナアクセス時に使われます。
 ホスト名は「musql」の他にも「socket」「localhost」という名前に変更できます。詳しくは、『サービス・コンテナへのアクセス』をご覧ください。


 サービス・コンテナへのアクセス

 サービスコンテナとして扱えるものは、データベースをだけではないと、先ほども述べました。
 サービスコンテナをもっと柔軟に活用することで、みなさんのAPIを手軽に拡張することができます。

 たとえば、Wordpressの拡張機能を作っており、テストをする必要があるとします。
 すると、サービスコンテナにwordpressを指定しておくという使い方が想定されます。

 まず、「.gitlab-ci.yml」に以下の設定を記述して、 tutum/wordpressイメージを立ち上げます。

======================
services:
 - tutum/wordpress:latest
======================

 tutum/wordpressにアクセスする時に使われるホストネームは以下の2つです。どちらかを選んでください。(サービスコンテナにエイリアスを設けてjobを実行したい場合は、別の設定が必要です。)

  • tutum-wordpress
  • tutum__wordpress

注:アンダースコア_を使ったホストネームは、RFCで認識されません。外部アプリケーションと連携する際に支障をきたす可能性があります。

 サービスコンテナのホスト名には、以下のルールに則って、なるべくコンテナの名前を連想しやすいエイリアスが設定されています。

  • servicesと、ホスト名は必ずコロン (:)で区切る
  • コンテナ名をホスト名にする際に、スラッシュ (/)をダブルアンダースコア (__)に置き換えた、第1エイリアスが作成される。
  • コンテナ名をホスト名にする際に、スラッシュ (/)をシングルダッシュ(-)に置き換えた、第2エイリアスが作成される。(GitLab Runner v1.1.0以上が必要)

 以上はあくまでデフォルトの設定です。このほかにも、サービスコンテナに特定のエイリアスを設けることもできます。それにつきましては、同文「「services」で使える設定オプション」にて説明します。


 .gitlab-ci.yml」から「image」と「services」を決定する

 実際にアプリケーションをビルドする時に、「images」と「services」を指定する時には、「.gitlab-ci.yml」ファイルから設定します。

 すべてのjobで同じイメージとサービスを使うときには、以下のような設定を加えます。

======================
image: ruby:2.2

services:

 - postgres:9.3 

before_script:

 - bundle install

test:

 script:

 - bundle exec rake spec
======================

 また、jobごとに異なるイメージとサービスを設けることも可能です。

======================
before_script:

 - bundle install

test:2.1:

 image: ruby:2.1

 services:

 - postgres:9.3

 script:

 - bundle exec rake spec

test:2.2:

 image: ruby:2.2

 services:

 - postgres:9.4  

 script:

 - bundle exec rake spec
======================

 あるいは、これから説明する拡張設定機能をイメージとサービスの設定に使ってみてもよいかもしれません。

======================
image:

 name: ruby:2.2

 entrypoint: ["/bin/bash"]

services:

 - name: my-postgres:9.4

 alias: db-postgres

 entrypoint: ["/usr/local/bin/db-postgres"]

 command: ["start"]

before_script:

- bundle install

test: 

 script:

 - bundle exec rake spec
======================


 Docker拡張設定オプション(原:Extended Docker configuration options)

 GitLab、GitLab Runner 9.4にて導入。

 「image」や「services」をさらに細かく具体的に指定したいときに、ストリングかマップ機能が使えます。

ストリングでコンテナを指定する時には、imageのフルネームを使わなくてはならない。(フルネーム=イメージが「どのレジストリにあるか」という情報も含む。Docker Hub以外のレジストリからイメージをダウンロードする時などに使うとよい。)

マップでコンテナを指定する時には、「name」でイメージを指定するのと同じように、フルネームを指定する。

 これから、ストリングとマップを使った設定例を1つずつ紹介します。どちらも結果的には同じ設定になっているので、どちらを好んで使うかの基準にしてください。

ストリングで「image」「services」を指定する

======================
image: "registry.example.com/my/image:latest"

services:

- postgresql:9.4

- redis:latest
======================

マップで「image」「services」を指定する

======================
image:

 name: "registry.example.com/my/image:latest"

services:

- name: postgresql:9.4

- name: redis:latest
======================



 「image」で使える設定オプション

 GitLab、GitLab Runner 9.4にて導入。

 設定には上記のGitLabバージョンを満たしている必要があります。

設定オプション 必須か GitLab バージョン 説明
name 必須です。他のどのオプションとも併用できます。 9.4 これから使うimageのフルネーム。
必要に応じて正しいレジストリ情報を記載してください。
entrypoint no 9.4 コンテナの「entrypoint」で実行するコマンドやスクリプトを指定します。Dockerの「--entrypoint」に当たる機能を、ymlファイルの記述法に変換しました。構文としてはDockerfile's ENTRYPOINTとよく似ており、それぞれのシェルトークンは、別々のストリングとして機能するようになっています。

 「services」で使える設定オプション

 GitLab、GitLab Runner 9.4にて導入。

 設定には上記のGitLabバージョンを満たしている必要があります。

設定オプション 必須か GitLab バージョン 説明
name 必須です。他のどのオプションとも併用できます。 9.4 これから使うimageのフルネーム。
必要に応じて正しいレジストリ情報を記載してください。
entrypoint no 9.4 コンテナの「entrypoint」で実行するコマンドやスクリプトを指定します。
Dockerの「--entrypoint」に当たる機能を、ymlファイルの記述法に変換したので、このような設定オプションになりました。
構文としてはDockerfile's ENTRYPOINTとよく似ており、それぞれのシェルトークンは、別々のストリングとして機能するようになっています。
command no 9.4 コンテナのコマンドとして実行されるコマンド、あるいはスクリプト。

Dockerのargumentsに相当する機能。必ずimageのname指定の後に実行されます。

構文としてはDockerfile's CMD とよく似ており、それぞれのシェルトークンは、別々のストリングとして機能するようになっています。
alias no 9.4 alias no 9.4 jobで必要とされるコンテナにアクセスする際に使われるエイリアスを追加します。
詳しくは、同文上の『サービス・コンテナへのアクセス』をご覧ください。

 同じイメージ内で様々なサービスコンテナを展開する

 GitLab、GitLab Runner 9.4にて導入。
 この機能を使いこなすには、まずは前章『Docker拡張設定オプション』を読んでおく必要があります。

 ここではDocker拡張設定オプションのさらに詳しい使い方を説明したいのですが、まずは絶対避けた方がよいコンフィグを紹介します。

======================
services:

- mysql:latest

- mysql:latest
======================

 なるほど「ランナーを起動したら、2つの『mysql:latest』コンテナを起動したかった」という気持ちだけならわかります。
 確かに、「mysql:latest」はデフォルトの状態での、mysqlコンテナ・ホスト名であることには違いありません。

 けれども、これは不適切な設定です。
 前の章ではかなり控えめにお伝えしましたが、ここに記述するコンテナ名は、それぞれのホスト名である必要があります。

 上のような設定をしてしまった場合、サービスコンテナのどちらか一方にしかアクセスが行き届かなくなることでしょう。

 ランナーというシステムは、コンテナをホスト名で見分けています。
 同じサービスを使っているコンテナが複数個ある場合は、それぞれにエイリアスをつけて、ランナー側がきちんと識別できるようにしておく必要があります。

 では正しい方法で、2つの「mysql:latest」を設置してみましょう。こちらです。

======================
services:

- name: mysql:latest

alias: mysql-1

- name: mysql:latest

alias: mysql-2
======================

 エイリアスは、皆さんが普段考えているDockerコンテナ名に数字を振るなど、簡単なもので構いません。ランナーが識別できさえすれば、サービスコンテナへのアクセスが正常に開始されるはずです。
 なお、この設定は「.gitlab-ci.yml」に記述します。サービスコンテナにアクセス障害が発生している場合は、このファイルに指定したコンテナ・ホスト名に重複がないかどうかを疑ってみてください。


 サービスコンテナ向けにコマンドを設定する 

 GitLab、GitLab Runner 9.4にて導入。
 この機能を使いこなすには、まず前章『Docker拡張設定オプション』(原:Extended Docker configuration options)を読んでおく必要があります。

 SQLデータベースにもいくつか種類がありますね。
 その中でも「super/sql:latest」イメージの使い方は、ちゃんとお伝えしなくてはなりません。

 このイメージは、「/usr/bin/super-sql run」というコマンドがないとデータベース業務を開始しません。そこで、サービスに対してコマンドを設置する操作が必須となります。

 ここで通常のDockerコンテナだったなら、CMDオプションを使って起動コマンドを設定します。たとえば、次のように。

======================
# my-super-sql:latest image's Dockerfile

FROM super/sql:latest

CMD ["/usr/bin/super-sql", "run"]
======================

 ところが、今回皆さんはGitLab CIを使っているので、「.gitlab-ci.yml」に設定をする必要があります。
 当然、表記はYAML記法です。
 CMDオプションは、「command: 」に変更になることにご注意ください。

======================
services:
- my-super-sql:latest


services:

- name: super/sql:latest

command: ["/usr/bin/super-sql", "run"]
======================

 とはいえ、[ ]内の表記については、 Dockerfileの CMDと何ら変わりがありません。


 イメージのエントリーポイントを優先させる

 GitLab、GitLab Runner 9.4にて導入。

 この機能を使いこなすには、まずは前章『Docker拡張設定オプション』を読んでおく必要があります。

 jobでテストを実行する時などに、テスト用のデータベースやバイナリが必要な場合があります。そのようなときに「super/sql:experimental」というDockerイメージなどを使用することがあります。これも中にSQLデータベースが入っています。

 これから「/usr/bin/super-sql run」というコマンドを、エントリーポイントで実行する設定をご紹介します。

 これは、コンテナを開始する際に一切の追加オプションを使用せず、jobの実施にデータベースプロセスだけを実行します。
 この設定を使うには、イメージコンテナ自体にはエントリーポイントが存在しない、あるいはエントリーポイントを設置していても、シェルを開始する時点のみであることが大条件となります。その条件が守られていない場合は、ランナーが設定を読み取れません。
 

 まず、通常のDockerコンフィグなら、次のようになることがイメージできますか。

======================
# my-super-sql:experimental image's Dockerfile

FROM super/sql:experimental

ENTRYPOINT ["/bin/sh"]
======================

 これらがYAML記法に合わせた表記になります。
 「.gitlab-ci.yml」に次の設定を施します。

======================
services:
- my-super-sql:latest

services:

- name: super/sql:experimental

entrypoint: ["/bin/sh"]
======================

 「ENTRYPOINT」が「entrypoint:」 に変更になりましたが、 [ ]内の記法は、 Dockerfileの ENTRYPOINTと同じです。

 config.toml」ファイルで「image」と「services」を定義する方法

 「config.toml」に[runners.docker]という項目を設けると、ランナーに実行させるDockerコンテナを一括で定義することができます。

======================
[runners.docker]

 image = "ruby:2.1"

 services = ["mysql:latest", "postgres:latest"]
======================

 このファイルに定義された「image」と「services」は、全てのjobで使われることになります。


 プライベート・コンテナレジストリから「image」を定義する

 注: 

  • この機能には、GitLab Runner 1.8以上が必要です。
  • GitLab Runnerが>= 0.6, <1.8 (0.6以上、1.8未満)のバージョンにおいては、プライベートレジストリへの対応が不可能ではないものの、手動でのホスト認証が必要です。
  • 最低限GitLab Runnerは、バージョン1.8を満たしていないと、プライベートレジストリが使用できません。
  • レポジトリの秘密を守り切るには、GitLab Runnerをレジストリ内に認証させる必要があります。
  • レポジトリの秘密を守り切るには、GitLab Runnerをレジストリ内に認証させる必要があります。この場合、GitLab Runnerがどのような動作を取るかについてはこちらのページに記載されています。

 次の例では、「registry.example.com/private/image:latest」というDockerイメージを使うように設定します。
 このイメージは、プライベートレジストリに置かれているため、ログインが必要です。

 よって、自動的にログインするための設定もしていきます。

必要なデータ 設定ファイルでの表記
レジストリのありか registry.example.com
ユーザ名 my_username
パスワード my_password

 

 「registry.example.com」にアクセスするように設定するには、次の工程を踏んでいきます。

  1. まずは、DOCKER_AUTH_CONFIG という環境変数を設定する。それには次の2つの方法がある。
    • 1つめ- ローカルマシン上のDockerコンテナにログインする方法

      ======================
      docker login registry.example.com --ユーザ名 my_username --パスワード my_password 
      ======================

      この内容を 「~/.docker/config.json」というファイルに保管する。
    • 2つめ- システムのキーストアからDockerクライアントに許可を出して、Dockerへのログインができるようにする方法。この場合でも「~/.docker/config.json」ファイルの読み込みが必要とされる。その準備として${username}:${password} のbase64-encodedバージョンを手動で作成する。

      ターミナルを開いて次のコマンドを実行する。

      ======================
      echo -n "my_username:my_password" | base64


      # すると、こんなかんじのが表示される。コピーしよう
      bXlfdXNlcm5hbWU6bXlfcGFzc3dvcmQ=
      ======================
  2. DOCKER_AUTH_CONFIG」という秘密変数を作成し、Dockerコンフィグレーションファイルには次のように設定する。
    ======================
    {
        "auths": {
          "registry.example.com": {
            "auth": "bXlfdXNlcm5hbWU6bXlfcGFzc3dvcmQ="
          }
        }
    }
    ======================

  3. さすがにこの設定は任意ですが、秘密変数「DOCKER_AUTH_CONFIG」に対して次のような設定をすると、Dockerから自動的にログアウト(docker logout)がなされる。レジストリへの不要なコンピューターアクセスを防ぐことができる。
    ===================== 
    docker logout registry.example.com
    ======================

  4. 上の3つの設定で「registry.example.com」に存在するどのコンテナイメージでも、imageやservicesに設定できるようになる。「.gitlab-ci.yml」に次の設定をすると…
    ======================
    image: my.registry.tld:5000/namespace/image:tag
    ======================
    my.registry.tld:5000/namespace/image:tag」というコンテナをイメージとして使用していることになっている。このコンテナが「registry.example.com」に存在していると考えてほしい。

 もっとたくさんのレジストリを使用したい場合には、2番の"auths" にハッシュを設けて、追加のレジストリを記述してください。


 サービスをより細かく設定する

 データベースではあまり珍しくない機能ですが、環境変数を使って、データベース名を変更したり、状況ごとにアカウント名をセットすることなどが可能な場合があります。

 GitLab Runner 0.5.0以上では、YAML定義変数でサービスコンテナに設定を加えることができます。

 イメージで使用できる環境変数は、それぞれのDocker hubページに記載されています。

 注:設定された環境変数は、全てのサービスコンテナに片っ端から適用されていきます。
現在のところランナーやコンテナには、どの環境変数が、どのコンテナに使われるものなのかを識別する機能はありません。

 PostgreSQLサービス設定例

 『PostgreSQLを使う』をご覧ください。

 MySQLサービス設定例

 『MySQLを使う』をご覧ください。

 Dockerインテグレーションの作動順序

  1. サービスコンテナ(mysql, postgresql, mongodb, redis等)の作成
  2. config.toml」ファイルと、ビルドイメージのDockerfileで定義された全てのボリュームを保持するために、キャッシュ・コンテナが作成される。(上の例では、ruby:2.1がビルドイメージとされていた)
  3. ビルドコンテナを作成して、全てのサービス・コンテナをビルドコンテナにリンクさせる
  4. ビルドコンテナが業務を開始して、jobスクリプトがコンテナに送られてくる
  5. jobスクリプトが実行される
  6. /builds/group-name/project-name/」内のコードが精査される
  7. .gitlab-ci.yml」に記述された全工程が実行される
  8. ビルドスクリプトが全て正常に完了したかが検査される
  9. ビルドコンテナとそれに関わる全てのサービスコンテナが削除される

 jobをローカル環境でデバッグする方法

注:これから紹介するコマンドは、ルート権がなくとも実行できるものです。
通常のユーザーアカウントであれば、Dockerの操作はできるようになっています。

まずは「build_script」という名前のファイルを作成します。

============================================
cat <<EOF > build_script
git clone https://gitlab.com/gitlab-org/gitlab-runner.git /builds/gitlab-org/gitlab-runner
cd /builds/gitlab-org/gitlab-runner
make

EOF
============================================

 上のコマンドで、GitLab Runnerレポジトリを作っています。
 レポジトリにはMakefileを収容しておきたいので、最後から2番目の行で「make」コマンドが記述されています。

 やり方に個人差はありますが、このコマンドは適用するプロジェクトをきちんと定義することが望ましいでしょう。

 そして、この「make」コマンドで具体的に何をするかについては、各プロジェクトで決定する方針です。

 次に、サービスコンテナを作ります。 

======================
docker run -d --name service-mysql mysql:latest
docker run -d --name service-postgres postgres:latest
======================

 これで2つのサービスコンテナが作られたはずです。それぞれ「service-mysql」「service-postgres」という名前がついていて、最新のMySQLとPostgreSQLを使用するように指定されています。
 そして、どちらもバックグラウンドで実行(-dオプション)されることになっています。

 最後に「build_script」を実行して、ビルドコンテナを立ち上げます。

============================================
docker run --name build -i --link=service-mysql:mysql --link=service-postgres:postgres ruby:2.1 /bin/bash < build_script
============================================

 このコマンドで、「ruby:2.1」イメージが2つのサービスと結びついた状態で作成されます。
 「--name build」とある通り、「build」という名前の付いたコンテナです。

 「build_script」については、Bash読み取りプログラムとしてSTDINを使用して、「build」コンテナ内で実行される見通しです。

 jobのテストが終了したら、これらのコンテナは用済みになります。コンテナの削除には次のコマンドを使います。

======================
docker rm -f -v build service-mysql service-postgres
======================

 (-f)とは『forcefully=強制的に』の頭文字です。これで「build」コンテナを削除します。
 それから(-v)で、コンテナによって作り出された全てのボリュームを削除します。これで残り2つのサービスコンテナも削除されます。

Edit this page

原文:https://docs.gitlab.com/ee/ci/docker/using_docker_images.html
原文ページプロジェクト並びにドキュメントファイルは、MIT Licenseのもと公開されています。(URL:https://gitlab.com/gitlab-com/gitlab-docs/blob/master/LICENSE) この記事の文章は、訳者の判断によりCreative Commons BY (version 3.0) を適用するものとします。
新着文書(Hnoss)

Signing legal documents
現在の位置: チームハンドブック 目次 >法的文書に署名する  法的文書への署名は、他社・他組織などに直接出向いてNDAsを取り扱った人物を除...
Team Handbook
現在の位置:チームハンドブック 目次  このハンドブックは、GitLabという企業が、どのようにサービスを維持運営していくかを記したものだ。ここに...
GitLab Pages documentation
  新しいドキュメント はこちらです。このドキュメントは旧式です。 GitLab Documentation > User documentation > Projects >GitLab P...
GitLab Pages
GitLab Documentation > User documentation > Projects >GitLab Pages 説明書  GitLab Pagesなら、無料でウェブサイトをホスティングできる...

新着文書

Social leader killed in Cordoba is fourth in same town in 2018
3月11日日曜日、地方評議会リーダーでアフリカ系コロンビア人の子孫であるトマス・バレトが、コルドバ県サン・ホセ・デ・ウレの自宅で殺害された。 2...

新着Wikipedia翻訳

E (programming language)
E(プログラミング言語) AmigaE や e(検証言語) 、 GNU E と混同しないこと。 E -------- パラダイム マルチパラダイム:オブジ...
Van Eck phreaking
Van Eck phreaking(ファン・エック・フリーク) Van Eck phreakingは盗聴の一形態であり、その中では特殊な装置が使用され、電子機器を探るため、隠...
Trusted Computer System Evaluation Criteria
Trusted Computer System Evaluation Criteria(信頼されたコンピュータ・システム評価基準) 【画像のキャプション】オレンジブック 信頼されたコ...

更新履歴

※文書量によっては処理に数十秒かかる場合があります
バージョン 比較対象 更新日時 更新者
1(最新) 2018-03-23 21:36:41 Hnoss
2 2017-12-21 22:31:09 Hnoss
3 2017-12-21 21:52:16 Hnoss
4 2017-12-21 21:51:48 Hnoss
5 2017-12-21 21:48:18 Hnoss
6 2017-12-21 21:44:28 Hnoss
7 2017-12-21 21:42:30 Hnoss
8 2017-12-21 21:31:29 Hnoss
9 2017-12-21 20:02:40 Hnoss
10 2017-12-21 14:45:58 Hnoss

    
ブックマーク登録

タグを「;(半角セミコロン)」区切りで入力して下さい(例)tag1;tag2;tag3
10タグまで登録可能。各タグ30文字まで

履歴
状態 作業中 作業予定あり 作業予定なし 作業完了
テーマ 社会 政治 法律 経済 文化 芸能 科学技術 IT 健康/医療 スポーツ メディア 植物 動物 菌類 地方 国際
地域 日本 東アジア アフリカ 南アジア 東南アジア 西アジア/中東 太平洋 北米 中南米 欧州
ジャンル ニュース 解説記事 論文 日記 百科事典

コメントを入力して下さい
0 / 250
    
ブックマーク登録

ブックマークに登録しました。


言語選択

    
ファイルプロパティ

使用許諾条件
ファイル情報
あなただけがこのファイルを閲覧・編集できます。
みんながこのファイルを閲覧できますが、
編集ができるのはあなただけです。
あなたに加えて、指定された人やグループが
このファイルを自由に閲覧・編集できます。
公開設定
編集設定
グループ:0組 翻訳者:0人
    
アクセス属性
この文書は「非公開」設定になっています。
一般公開する場合は、編集ページの書誌情報で「公開」設定に変更して下さい。
翻訳者選択

※メニュー「翻訳者管理」で翻訳者、グループを追加することができます。


    
ノート

非公開ノート
0 / 2000 ※「公開・編集」権限を持つ翻訳者のみに公開されます。
公開ノート
0 / 2000 ※文書を「公開」にした場合、一般に公開されます。

言語選択

 →