「みんなの翻訳」は、世界中の文書をみんなで協力して翻訳するサイトです。

みんなの翻訳ロゴ
ブクタブ
翻訳サイト

カテゴリ一覧

このサイトについて 新規登録はこちら お試し翻訳

一覧

2017/07/28

メンテナンス終了のお知らせ

2017/7/25-2017/7/28に実施したメンテナンスは、2017/7/28/14:20に終了いたしました。 ご協力をいただき、ありが…

List

kyo2018

English⇒Japanese

Hnoss

English⇒Japanese

yasukazu

English⇒Japanese

shikimi

English⇒Japanese

ホーム新着翻訳記事一覧 > 新着翻訳記事

新着翻訳記事

【GitLab 公式 を訳してみた】Dockerエクゼキュータ

GitLab Runnerエクゼキュータ>Dockerエクゼキュータ 

  GitLab ランナーでは、ユーザーが用意したイメージにアプリをビルドする際に、Dockerを利用することができます。ただし、それにはDockerエクゼキュータの利用が必須です。

  DockerエクゼキュータがGitLab CIで使用された場合、ランナーはDockerエンジンへ接続して、ユーザー定義済みコンテナ(隔離された環境)でアプリのビルドを開始します。
 どの定義済みコンテナを利用するかは、「.gitlab-ci.yml」か「config.toml」ファイルで設定します。

  これにより設定されたCIコンテナは、本来我々が手作業で構築していたはずの「ビルド環境」というものを、ほとんど完璧に再現します。
 設定によっては、ビルドを終えたアプリケーションを、そのままワークステーションに提出することが可能です。
 皆さんは全てのコマンドを試験するときなどに、あらかじめ細工しておいたシェルを用いて、その合否を確かめていたことでしょう。ですが、そこを専用のCIサーバーに集約することで、様々な工程を一本化できます。
 

 目次
>全体の作業工程
>「image」で使われるキーワード
>「services」で使われるキーワード
 >サービスをビルド工程と連携させる方法
>「.gitlab-ci.yml」から「image」と「services」を決定する方法
>「config.toml」ファイルで「image」と「services」を定義する方法
>プライベート・コンテナレジストリから「image」を定義する
>サービス・コンテナへのアクセス
>サービスをより細かく設定する
>ディレクトリをRAMにマウントする
>ビルドディレクトリをサービスコンテナ内に設ける
 >PostgreSQLサービス設定例
 >MySQLサービス設定例
 >サービスコンテナのヘルス・チェック
>ビルド物と、キャッシュストレージの保管場所
>永続的ストレージ
>永続的ストレージをビルドディレクトリに設定する
>特権モード
 >docker-in-docker(Dockerの中のDocker)で特権モードを使う
>エントリーポイント
>pull policiesパラメータとは
 >「never」モード
 >「if-not-present」モード
 >「always」モード
>Docker vs Docker-SSH (それから Docker+Machine vs Docker-SSH+Machineについても。)


 

  全体の作業工程

 Dockerエクゼキュータでビルドする時には、大まかに次のような手順を踏みます。

  1. 準備:サービスコンテナを作成、開始させる
  2. ビルド前:キャッシュをクローン、リストアして、前のステージからアーティファクトをダウンロードしてくる。これは専用のDockerイメージ上で実行される。
  3. ビルド:ユーザービルド。ここではユーザーが用意したDockerイメージが使われる。
  4. ビルド後:キャッシュを作成し、アーティファクトをGitLabにアップロードする。これは専用のDockerイメージ上で実行される。


 ビルドの端々で使用されている「専用Dockerイメージ」は、Alpine Linuxをベースとしたもので、ビルドの準備に当たって必要なツール類などが全て封入されています。Gitのバイナリとランナーのバイナリと歯、ここで作成されるキャッシュとアーティファクトに対応するように設計されているのです。
 専用イメージの詳細な定義については、公式ランナーレポジトリに記載されています。


 

   「image」で使われるキーワード

  「image」で使われるキーワードは、Dockerイメージの名称そのものです。ここには、ローカル環境のDockerエンジン内にあるDockerイメージ(『docker imeges』で定義されている全てのイメージ)か、Docker Hubに掲載されているイメージを指定できます。 Docker Hubの詳しい利用方法については、Docker Fundamentalsというガイダンスに詳しく記載されています。
 

  間違えないでほしいのは、この説明書での「イメージ」はあくまでDockerイメージのことです。このコンテナでアプリケーションがビルドされ、さらには動作することになります。

 イメージにこれといった名前空間を指定しなかった場合は、Dockerは全ての公式イメージに含まれているライブラリを導入します。 
 「gitlab-ci.yml」や「config.toml」で何らかのイメージを指定すると、そこから必要なライブラリだけが抜き出されます。たとえば、「image: ruby:2.1」と指定すると、全てのライブラリから「image: library/ruby:2.1」だけが切り抜かれていると考えていただけるとわかりやすいでしょう。
 

  それから、それぞれのDockerイメージには「タグ」がついています。これにはイメージのバージョンが記されています。Dockerイメージ名の後にコロン (:) をつけて定義します。
  たとえば、「Ruby」のイメージに定義できるタグは、こちらの https://hub.docker.com/_/ruby/
というページに掲載されているバージョンです。
 タグを使ってバージョンを指定しなかった(たとえば、『image: ruby』とだけ定義するような)場合は、それぞれのイメージの最新版(latest)が適用されることになります。よって、このオプションはよほどバージョンによる互換性が心配な場合を除いては、指定する必要はないでしょう。

 

   services」で使われるキーワード

  「service」は、補佐的なDockerイメージを定義するキーワードです。ここで定義されたサービスは、ビルドの間だけ起動して、「image」で定義されたDockerイメージと連動して動作ます。ここで定義されたサービス用Dockerイメージは、ビルドの際になって初めてアクセスが開始されます。

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

   こちらのCIサービス設定例というページでは、ビルド環境にどのようにしてサービスコンテナを設置したかの実例が紹介されています。

 

  サービスをビルド工程と連携させる方法

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

   かいつまんでいえば、「mysql」をサービスとして追加した場合、Dockerイメージはビルドコンテナとリンクしたサービスコンテナを使うようになるという話です。
 従って、先ほど『全体の作業工程』の章でお伝えしたとおり、最初の「準備:」で実施する作業がちょうどこれにあたります。

  たとえば、「MySQL」コンテナがビルドコンテナと連携するように設定したなら、その時のホスト名は「mysql」となっており、これがイメージによるサービスコンテナアクセス時に使われます。
 なお、ホスト名は「mysql」の他にも「socket」「localhost」という名前に変更できます。

 

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

  アプリケーションをビルドする時に、すべてのjobで同じイメージとサービスを使うのなら、「.gitlab-ci.yml」ファイルから以下のような設定を加えます。

======================
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
====================== 

 

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

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

======================
[runners.docker]
 image = "ruby:2.1"
 services = ["mysql:latest", "postgres:latest"]
======================

  このファイルに定義された「image」と「services」は、全てのjobで使われることになります。
 なので、「.gitlab-ci.yml」でイメージなどが指定されていない場合でも、「config.toml」に記載されているイメージ、サービスが適用されます。

 

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

  この機能はGitLab Runner 0.6.0から導入されました。プライベートレジストリを利用するには、GitLab Runnerのバージョンが「0.6.0」以上であることが求められます。
 

  プライベートレジストリにあるコンテナを使用する時には、「.gitlab-ci.yml」ファイルにイメージを以下のように指定する必要があります。かなり細かいです。

======================
image: my.registry.tld:5000/namepace/image:tag
====================== 

  上の例では「/namespace/image:tag」から「my.registry.tld:5000」というコンテナをランナーが探し出して、イメージとして使用していることになっています。

  レポジトリの秘密を守り切るには、GitLab Runnerをレジストリ内に認証させる必要があります。
 詳しくは「using a private Docker registry」をご覧ください。

 

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

  Wordpressの拡張機能を作っていることを想定して、APIインテグレーションにテストが必要だとします。
 そこから、サービスコンテナへのアクセスを設定する方法をご説明します。

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

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

  tutum/wordpressにアクセスする時に使われるホストネームは「tutum__wordpress」「tutum-wordpress」の2つです。どちらかを選んでください。

  GitLab Runnerでは、サービスにもうけられている2つのホスト名にエイリアスを設けることができます。以下のルールに従う必要がありますが、ホスト名の代案として検討していただくとよいでしょう。

  1. 変数はコロン (:)の後に設定します
  2. 最初のエイリアスでは、スラッシュ (/) は ダブルアンダースコア (__)に置き換えられます
  3. 2番目のエイリアスでは、スラッシュ (/) は シングルダッシュ (-) に置き換えられます

 とくに、プライベートサービス/イメージを使用する時には、これらのルールに従って独自にポート名を変更することが十分に考えられます。
 たとえば、 「registry.gitlab-wp.com:4999/tutum/wordpress」というイメージに「tutum__wordpress」「tutum-wordpress」というポート名を設けたら、ホスト名はそれぞれ「registry.gitlab-wp.com__tutum__wordpress」「registry.gitlab-wp.com-tutum-wordpress」になります。


 

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

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

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

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

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

 

  ディレクトリをRAMにマウントする

  「tmpfs」を使うことで、ディレクトリにRAMへのパスを設けることが可能です。とくに、データベースなど、処理に「I/O」が深く関わっているようなディレクトリに関しては、テストの速度向上が見込まれます。
 ランナーの設定で「tmpfs」と「services_tmpfs」オプションを使う場合、それぞれのオプションごとに複数のパスを追加することができます。この機能については、docker referenceにより詳細な情報が載っています。
 ここではまず簡単な例として、config.tomlで「公式のMysqlコンテナが入っているディレクトリをRAMにマウントする」設定を紹介します。
 

======================
[runners.docker]
 # これはメインのコンテナを対象にした設定
 [runners.docker.tmpfs]
   "/var/lib/mysql" = "rw,noexec"

 # これはサービスコンテナ用
 [runners.docker.services_tmpfs]
   "/var/lib/mysql" = "rw,noexec"
======================

 

  ビルドディレクトリをサービスコンテナ内に設ける

  「/builds」ディレクトリを全共有サービスコンテナにマウントさせる機能は、GitLab Runner 1.5 で導入されました。

  詳しくは、こちらのイシューをご覧ください:https://gitlab.com/gitlab-org/gitlab-runner/issues/1520

 

   PostgreSQLサービス設定例

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

  MySQLサービス設定例

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

 

  サービスコンテナのヘルス・チェック

  サービスを作動させると、GitLab Runnerはしばらくの間サービスコンテナからの応答を待ちます。Dockerエクゼキュータがサービスコンテナへの接続を試みる際に、TCPコネクションを使用するように努めますが、その接続にやや時間を要する場合があります。
 たいていが、その接続が成功するのを待っていることがほとんどです。

  この機能については、こちらのページに記載されています。

 

  ビルド物と、キャッシュストレージの保管場所

  デフォルトの状態でのDockerエクゼキュータは、全てのビルド物を「/builds//」、そして全てのキャッシュを同コンテナの「/cache」ディレクトリに収容します。

  「/builds」「/cache」ディレクトリの置き場所は、config.toml[[runners]] セクションに「builds_dir」「cache_dir」オプションを追加することで上書きできます。コンテナ内でのデータの置き場所に変更を加えたいときなどは、この操作を行ってください。
 

  「/cache」ストレージのパスを変更した場合は、config.toml [runners.docker]セクションに「volumes = ["/my/cache/"] 」などのように、変更先ディレクトリをきちんと指定する必要があります。

  これについては、次の章『永続的ストレージ』でご説明いたします。

 

  永続的ストレージ

  Dockerエクゼキュータは、コンテナを動作させるときに、永続的ストレージを利用することができます。
 「volumes = 」で定義された全てのディレクトリは、ビルドの間は永続的ストレージに格納されることになります。

  「volumes」に充てられるストレージは、次の2種類です。

  1. <path > - 動的ストレージ用<path>で指定されたストレージは、その後のjobまでずっと共有して使われることになる。中のデータは、カスタムキャッシュコンテナに収容されることになる。→そのコンテナ:runner-<short-token>-project-<id>-concurrent-<job-id>-cache-<unique-id>
  2. <host-path>:<path>[:<mode>] - ホスト直属のストレージ用。これは<path>ストレージが、ホストシステム上の<host-path>に結び付けられている状態を表している。<mode>には、デフォルトで読み書き両用(read-write)ストレージが設定されているが、任意で読みこみ専用(read-only)ストレージに変更することが可能。

  永続的ストレージをビルドディレクトリに設定する

/builds」ディレクトリを、ホスト直属のストレージにした場合:/builds/<short-token>/<concurrent-id>/<名前空間>/<プロジェクト名>

 

  • <short-token>は、ランナーのトークン名(デフォルトでは8単語)を短くしたもの。
  • <concurrent-id>は、プロジェクトで使われている専用のランナーが、ローカルjobIDを識別するのに使っている固有番号のこと。


 

  特権モード

 

  Dockerエクゼキュータは、ビルドコンテナを調整するために数多くのオプションに対応しております。その中の1つに「特権モード」を取り付けられる機能があります。
 

  docker-in-docker(Dockerの中のDocker)で特権モードを使う

  この設定では、ビルドコンテナと全てのサービスコンテナを使うのに、そのつど権限認証を求める操作(privileged フラグ)を行います。これにはdocker-in-dockerを使うのがもっとも簡単です。

  まずは、「config.toml」でランナーがprivilegedモードで動作するように設定します。

 

======================
 [[runners]]
  executor = "docker"
  [runners.docker]
   privileged = true
======================
 

  それから、「.gitlab-ci.yml」でビルドスクリプトが、Docker-in-Dockerコンテナを対象に動くように設定します。

======================
image: docker:git
services:
- docker:dind

build:
 script:
 - docker build -t my-image .
 - docker push my-image
======================

 

  エントリーポイント

  Dockerエクゼキュータでは、DockerイメージのENTRYPOINTを上書きすることができません。

  これはすなわち、皆さんのイメージでENTRYPOINTを定義していた場合は、スクリプトをCMDで動作させることが許容されていないことを表しています。CMDを使ってしまった場合は、イメージをDockerエクゼキュータで動作させることができなくなってしまうからです。

  ENTRYPOINTが扱えるのは、custom environment か secure modeの状態でビルドスクリプトを動かせる特殊なDockerイメージだけです。ENTRYPOINTをお使いをご検討の場合は、そのようなイメージを用意しておくことをおすすめします。

  みなさん、ENTRYPOINTを使うとビルドスクリプトが実行されないように勘違いされる方が多いのですが、実際は定義済みコマンドのセットを実行しているだけです。
 たとえば、ディレクトリからDockerイメージをビルドすることなどが、この操作で可能なことです。その場合、ビルドコンテナは特権モードで動作する仕様になっており、ビルド環境がランナーにとって安全なものになっていなくてはなりません。
 

  その設定は、大まかに次のような手順を取ります。

  1.新しくDockerfileを作成

======================
FROM docker:dind
ADD / /entrypoint.sh
ENTRYPOINT ["/bin/sh", "/entrypoint.sh"]
======================
 

  2.「entrypoint.sh」ファイルにbashスクリプトを作成します。これがRNTRYPOINTで使われることになるでしょう。

======================
#!/bin/sh

dind docker daemon
  --host=unix:///var/run/docker.sock \
  --host=tcp://0.0.0.0:2375 \
  --storage-driver=vf &

docker build -t "$BUILD_IMAGE" .
docker push "$BUILD_IMAGE"
======================
 (¥はバックスラッシュの誤変換)
 

  3.Dockerレジストリにイメージをプッシュします。

  4.Dockerエクゼキュータを特権モードで扱うように設定します。「config.toml」に以下のように記述してください。

======================
[[runners]]
 executor = "docker"
 [runners.docker]
  privileged = true
======================

  5.プロジェクトの「.gitlab-ci.yml」には次のように設定します。

======================
variables:
 BUILD_IMAGE: my.image

build:
 image: my/docker-build:image
 script:
 - Dummy Script
======================
 

  これはあくまでほんの一例にすぎません。他の方法だってありますし、実際にはさらにもっと多くのオプションをつけることも可能です。

 

  pull policiesパラメータとは

  エクゼキュータにdocker、あるいはdocker+machineを採用しているときには、「pull_policy」パラメータの使用が可能です。これはランナーがDockerコンテナ(イメージ/サビス両方を含む)を引き出したら、次はどのような動作に移るかを定義します。

  注:pull_policy」がとくに定義されなかった場合は、「always」がデフォルトの設定として使われることになります。

  それでは、policiesにどのようなモードがあるのかをを見てましょう。
 

  never」モード

  これは、一切のDockerコンテナの引き出しを規制するプルポリシーです。「pull_policy」パラメータを「never」に設定した場合、皆さんはランナーで使っていく全てのイメージを手動で引き込むことになります。

  もしもローカル環境に目当てのDockerコンテナが見つからなかった場合、ランナーのビルドは成立せず、エラーが出ることになります。

======================
Pulling docker image local_image:latest ...

ERROR: Build failed: Error: image local_image:latest not found
======================

  このモードが有効な場面は?

  たとえば、使用するイメージには細心の注意を払わなくてはならない状況で、ランナーの使用者が「ビルドにどのような材料を使っているか」をきちんと監視しなくてはならない場面ですね。
 プロジェクトチームで、どのDockerイメージを使用するかが予め決定されているときなどは有効な選択肢でしょう。(特にこの場合、イメージ内に他チームに真似されては惜しいものが入っており、レジストリに置くわけにもいかないことが想定されます)

 

  このモードが不利な場面は?

  このポリシーが不利に働くのは、オートスケーリング機能つきDockerエクゼキュータを使用している場合です。
 なぜならオートスケーリング機能そのものが、クラウドコンピューティングでの使用を想定したものだからです。クラウドでランナーを使用している場合、そこではサーバーのプロバイダが指定した「定義済みイメージ」しか使えません。すると、プルポリシーを設けても対応してくれない場合がほとんどだからです。

 なので、このモードを使用する際には、Dockerエンジンがインストールされた状態で、ローカル環境からイメージを持ってこられる状態であることが前提となります。

 

  if-not-present」モード

  このモードを使う前には、必ずローカル環境にDockerイメージが準備されているかどうかをご確認ください。あくまでローカル環境のイメージを使うように設計されています。適切なイメージが発見されなかった場合、ランナーは延々とイメージを探し続けます。
 

  このモードが有効な場面は?

  もしも、ランナーで使いたいイメージがリモートレジストリにあって、そのイメージをかなりの頻度で使っているうえに、めったにアップデートしない予定であるとします。すると、イメージのレイヤー間の差などの状態をいちいち計測しなおす時間がもったいないわけです。
 この際、イメージをアップデートする機会は少ないのですから、いっそ手動で古いイメージをDockerエンジンから削除して、新しいものに入れ換えた方がよいのではないでしょうか。

  さらに、この方法の良いところは、ビルドに使用するイメージは”ローカル環境のものだけ”と言いながらも、”リモートレジストリから”引用することが可能であることです。
 

  このモードが不利な場面は?

  ただ、先ほども述べた通り、このモードが有利なのは「イメージのアップデートが少ない」環境です。セキュリティの都合などで、アップデートをしょっちゅう行わなくてはならない状況ではお勧めできません。

 たとえば、ローカル環境のイメージを更新したら、それを使っている全てのプロジェクトに等しくコピーをかけていかなくてはなりません。もしも、その際に発生する通信に意味がなかったとしたら、もったいない話です。
 つまり、無駄なネットワーク負荷を抑制するために、このモードが設計されたことをご理解ください。

  さらに、このモードはランナーの使用者が複数人おり、お互いに閲覧されたくないプライベートイメージを抱えている場合には、使用をお控えください。
 特に共有ランナーを使用する場合については、決してこのモードを使ってはなりません。

  「if-not-present」モードとプライベートイメージの併用が、なぜセキュリティ的に相性が悪いのかは、こちらのsecurity considerations documentationをお読みいただければ、ご理解いただけるでしょう。

 

  always」モード

  いつでも安定して最新のDockerイメージを使うようにするモードです。これを使っている限りは、ローカル環境のイメージも含めて、いつでも最新のものをコピーしようとしますので、イメージが古くなることがありません。
 適切なイメージが見つからなかった場合は、ビルドそのものが中止され、エラーが表示されます。

======================
Pulling docker image registry.tld/my/image:latest ...
ERROR: Build failed: Error: image registry.tld/my/image:latest not found
======================

  注:上記のエラーが表示されるのは、v1.8以降です。それ以前のバージョンでalwaysモードを使った場合は、イメージのローカルコピーを代用することができます。その際に次の警告文が表示されます。

============================================
Pulling docker image registry.tld/my/image:latest ...
WARNING: Cannot pull the latest version of image registry.tld/my/image:latest : Error: image registry.tld/my/image:latest not found
WARNING: Locally found image will be used instead.
============================================

  これがv1.8で変更になりました。何故この方法を取りやめたかについては、こちらのイシュー #1905に詳しく明かされています。
 

  このモードが有効な場面は?

  ランナーが公開されている、共有して使われるように設定されている場合です。 プライベートイメージを使用する時にも、最新状態に保たれやすいことから、それなりに安全であると言える唯一のモードと言えるでしょう。

  とにかく、イメージが古くならないことが最大の長所です。

  これを使っている分には、オートスケール機能つきDockerをエクゼキュータにしているランナーでも問題なく扱えます。
 

  このモードが不利な場面は?

  このモードは、ローカル環境に収容しているイメージだけを使わなくてはならない場面では、うまく動かない可能性が高いと言えます。このモードは、ローカル環境にあるイメージをコピーする段階を飛ばして、リモートレジストリを探すことに注力することが多いからです。
 Dockerイメージをローカルでビルドして、公開レジストリ(特にデフォルトのDockerレジストリ)を全く使用しない場合には、アプリケーションのビルドが失敗する場合があります。
 ビルドに失敗すると、以下のような表示がされます。

======================
Pulling docker image local_image:latest ...
ERROR: Build failed: Error: image local_image:latest not found
======================

 

  Docker vs Docker-SSH (それから Docker+Machine vs Docker-SSH+Machineについても。)

 注:GitLab Runner 10.0から、docker-ssh 並びに docker-ssh+machineエクゼキュータの使用は、非推奨となりました。近々のアップデートでこれらのエクゼキュータは削除される見通しです。

  Dockerエクゼキュータには少し特殊なものがいくつかあります。その1つがDocker-SSH(オートスケールを使っている場合は『Docker-SSH+Machine』)です。Docker-SSHエクゼキュータは、Dockerエクゼキュータと同じ理論で動いています。ですが、Dockerエクゼキュータがスクリプトを何の障壁もなく直接利用するのに対し、Docker-SSHエクゼキュータはビルドコンテナへの接続にSSHクライアントを利用します。

  Docker-sshエクゼキュータが接続するSSHサーバーは、内部IPを使用したコンテナの中で運用されています。

  このエクゼキュータは近い将来、開発を終了し、公式からは抹消される予定です。

 Edit this page

 

 
PDF
更新日:2018-03-23 21:41:36 Hnoss 0  del.icio.usに追加   はてなブックマークに追加   twitterに投稿   facebookでshare
[ 原文 ] https://docs.gitlab.com/runner/executors/docker.html 原文ページプロジェクト並びにドキュメントファイルは、MIT Licenseのもと公開されています。(URL:https://gitlab.com/gitlab-com/gitlab-docs/blob/master/LICENSE) この記事の文章は、訳者の判断によりCreative Commons BY (version 3.0) を適用するものとします。
翻訳者ページをみる

この記事の翻訳者

Hnoss さんの翻訳記事

[翻訳]GitLabハンドブック>法的文書に署名する

現在の位置: チームハンドブック 目次 >法的文書に署名する  法的文書への署名は、他社・他組織などに直接出向いてNDAsを取り扱った人物を除いては、Cレベル エクゼクティブのみが…2018-04-07 23:31:41

[翻訳]GitLabハンドブック

現在の位置:チームハンドブック 目次  このハンドブックは、GitLabという企業が、どのようにサービスを維持運営していくかを記したものだ。ここに書かれていることが、わが社の中核レ…2018-04-07 23:18:22

【GitLab Pages 公式 を訳してみた】GitLab Pages 説明書 

  新しいドキュメント はこちらです。このドキュメントは旧式です。 GitLab Documentation > User documentation > Projects >GitLab Pages 説明書 …2018-04-06 16:52:11

【GitLab 公式 を訳してみた】GitLab Pages 説明書(改訂版)

GitLab Documentation > User documentation > Projects >GitLab Pages 説明書  GitLab Pagesなら、無料でウェブサイトをホスティングできる。  GitLabにプロジェクトレポジト…2018-04-06 16:50:36