nomad driver containerd
Version 0.9.4
私たちは、このプロジェクトの貢献者とメンテナーを積極的に探しています。コンテナの内部の経験があるのは、cgroup、名前空間、またはdocker 、 containerd 、 nerdctl 、 podmanなどのコンテナに関するオープンソースプロジェクトに貢献しているか、コンテナの内部に対処し、このプロジェクトに貢献することに興味があるツーリングを構築する場合、私はあなたと話をするのが大好きです！ Golangの経験が望ましいが、必要ではない。
このプロジェクトに貢献することに興味がある場合は、 @_shishir_mに連絡するか、このリポジトリで連絡先の詳細を掲載してください。
Containerdを使用してコンテナを起動するためのNomadタスクドライバー。
containerd (containerd.io)は、コンテナライフサイクルを実行および管理するための軽量コンテナデーモンです。
Docker DaemonはContainerdも使用します。
dockerd (docker daemon) --> containerd --> containerd-shim --> runc
nomad-driver-containerdは、 DockerなしでContainRDを使用して、Nomad Clientがコンテナを直接起動できるようにします。
Dockerデーモンはホストシステムでは必要ありません。
$ gopathが正しくセットアップされていることを確認してください。
$ mkdir -p $GOPATH/src/github.com/Roblox
$ cd $GOPATH/src/github.com/Roblox
$ git clone [email protected]:Roblox/nomad-driver-containerd.git
$ cd nomad-driver-containerd
$ make build (This will build your containerd-driver binary)
arm64をコンパイルしたい場合は、実行できます。
make -f Makefile.arm64
$ vagrant up
または、Vagrant VMが既に実行されている場合、 vagrant provision 。
セットアップ（ vagrant upまたはvagrant provision ）が完了し、Nomadサーバーが稼働していると、登録されたタスクドライバー（ containerd-driverも表示されます）を確認できます。
$ nomad node status (Note down the <node_id>)
$ nomad node status <node_id> | grep containerd-driver
注： setup.sh浮浪者セットアップの一部であり、直接実行しないでください。
exampleディレクトリにジョブの例はほとんどありません。
$ nomad job run <job_name.nomad>
仕事を開始します。
より詳細な指示はexample README.mdにあります
imagesやcontainersと直接対話するには、 containerdのDocker互換CLIであるnerdctl使用できます。 nerdctlはすでにVAGRANT VM AT /usr/local/binにインストールされています。
ドライバー構成
| オプション | タイプ | 必須 | デフォルト | 説明 |
|---|---|---|---|---|
| 有効になっています | ブール | いいえ | 真実 | タスクドライバーを有効/無効にします。 |
| containerd_runtime | 弦 | はい | n/a | io.containerd.runc.v1またはio.containerd.runc.v2のcontaind eg io.containerd.runc.v1のランタイム |
| stats_interval | 弦 | いいえ | 1秒 | TaskStatsを収集するための間隔。 |
| Alow_privileged | ブール | いいえ | 真実 | falseに設定されている場合、ドライバーは特権的な仕事を実行することを拒否します。 |
| 認証 | ブロック | いいえ | n/a | プライベートレジストリに認証を提供します。詳細については、認証を参照してください。 |
タスク構成
| オプション | タイプ | 必須 | 説明 |
|---|---|---|---|
| 画像 | 弦 | はい | コンテナ用のOCI画像（DockerもOCI互換性があります）。 |
| image_pull_timeout | 弦 | いいえ | imageで指定されているように、OCI画像の進行中のプルをキャンセルする前に、 containerd-driverが待機する時間を制御する期間。デフォルトは"5m"になります。 |
| 指示 | 弦 | いいえ | 画像で定義されているコマンドをオーバーライドするコマンド。 |
| args | []弦 | いいえ | コマンドの引数。 |
| エントリポイント | []弦 | いいえ | 画像のエントリポイントをオーバーライドする文字列リスト。 |
| CWD | 弦 | いいえ | コンテナプロセスの現在の作業ディレクトリを指定します。ディレクトリが存在しない場合、1つは作成されます。 |
| 特権 | ブール | いいえ | 特権モードでコンテナを実行します。特権モードで実行するとき、コンテナにはすべてのLinux機能があります。 |
| pids_limit | INT64 | いいえ | コンテナのPID制限を指定する整数値。デフォルトは無制限です。 |
| PID_MODE | 弦 | いいえ | hostまたはセット（デフォルト）。 hostに設定して、PIDネームスペースをホストと共有します。 |
| ホスト名 | 弦 | いいえ | コンテナに割り当てるホスト名。このオプションセットで複数のタスク（ countを使用）を起動すると、タスクが起動するすべてのコンテナには同じホスト名があります。 |
| host_dns | ブール | いいえ | デフォルト（ true ）。デフォルトでは、 containerd-driverを使用して起動されたコンテナは、host /etc/resolv.confを使用します。これはdocker behaviorに似ています。ただし、ホストDNSを使用したくない場合は、 host_dns=falseを設定してこのフラグをオフにすることができます。 |
| seccomp | ブール | いいえ | デフォルトのSECCOMPプロファイルを有効にします。 allowed syscallsのリスト。 |
| seccomp_profile | 弦 | いいえ | カスタムSECCOMPプロファイルへのパス。 seccomp_profileを使用するには、 seccompをtrue設定する必要があります。 hereあるデフォルトのdocker SecCompプロファイルは、参照として使用し、カスタムSECCOMPプロファイルを作成するように変更できます。 |
| shm_size | 弦 | いいえ | /dev /shmのサイズ /dev /dev /shmの128 MBが必要な場合。 |
| sysctl | マップ[文字列]文字列 | いいえ | STARTでコンテナに設定するSYSCTL構成のキー価値マップ。 |
| readonly_rootfs | ブール | いいえ | コンテナルートファイルシステムは読み取り専用です。 |
| host_network | ブール | いいえ | ホストネットワークを有効にします。これは--net=hostに相当します。 |
| extra_hosts | []弦 | いいえ | ホストとして指定されたホストのリスト：IP、 /etc /ホストに追加される。 |
| cap_add | []弦 | いいえ | 個々の機能を追加します。 |
| cap_drop | []弦 | いいえ | 無効な機能をドロップします。 |
| デバイス | []弦 | いいえ | コンテナにさらされるデバイスのリスト。 |
| 認証 | ブロック | いいえ | プライベートレジストリに認証を提供します。詳細については、認証を参照してください。 |
| マウント | []ブロック | いいえ | 容器に取り付けられるマウントのリスト。ボリューム、バインド、およびTMPFSタイプマウントがサポートされています。 FSTABスタイルmount optionsがサポートされています。 |
マウントブロック
{
-Type （String）（オプション）：サポートされた値は、 volume 、 bind 、またはtmpfsです。デフォルト：ボリューム。
-ターゲット（文字列）（必須）：コンテナ内のターゲットパス。
-source （string）（optional）：ホストのソースパス。
-オプション（[]文字列）（オプション）：FSTABスタイルmount options 。注：バインドマウントには、少なくともrbindとro必要です。
}
マウントの例をバインドします
mounts = [
{
type = "bind"
target = "/target/t1"
source = "/src/s1"
options = ["rbind", "ro"]
}
]
Task Configのアディmountsオプションオプションでは、nomad volume_mount stanzaを使用してボリュームをコンテナにマウントすることもできます。
volume_mountのexample jobを参照してください。
カスタムSECCOMPプロファイルの例
hereあるデフォルトのdocker SecCompプロファイルは、ダウンロードして（syscallsを削除/追加することにより）変更して、カスタムSECCOMPプロファイルを作成できます。
カスタムSECCOMPプロファイルは、NOMADクライアントノードで/opt/seccomp/seccomp.jsonの下で保存できます。
このカスタムSECCOMPプロファイルを使用して、NOMADジョブを起動できます。
config {
seccomp = true
seccomp_profile = "/opt/seccomp/seccomp.json"
}
sysctlの例
config {
sysctl = {
"net.core.somaxconn" = "16384"
"net.ipv4.ip_forward" = "1"
}
}
auth Stanzaを使用すると、Docker Hubのプライベートリポジトリから画像を取得する場合、プライベートレジストリの資格情報を設定できます。
auth Stanzaは、 Driver ConfigまたはTask Config 、またはその両方で設定できます。
両方の場所に設定されている場合、 Task Config AUTHはDriver Config AUTHよりも優先されます。
注：以下の例では、 userとpass 、資格情報を指定するときに、実際のusernameとpasswordに置き換える必要があるプレースホルダー値です。以下のauth StanzaはDriver ConfigとTask Config両方に使用できます。
auth {
username = "user"
password = "pass"
}
nomad-driver-containerdホストおよびブリッジネットワークをサポートしています。
注： hostとbridge相互に排他的なオプションであり、そのうちの1つだけが一度に使用する必要があります。
ホストネットワークは、 host_networkジョブ仕様のタスク構成でtrueに設定することで有効にできます（ Supported optionsを参照）。
ブリッジネットワークは、ジョブ仕様のタスクグループセクションにnetworkスタンザを設定することで有効にできます。
network {
mode = "bridge"
}
bridgeネットワークを使用する前に、 /opt/cni/binの下にNOMADクライアントノードにCNIプラグインをインストールする必要があります。
CNIプラグインをインストールする手順。
$ curl -L -o cni-plugins.tgz https://github.com/containernetworking/plugins/releases/download/v0.8.6/cni-plugins-linux-amd64-v0.8.6.tgz
$ sudo mkdir -p /opt/cni/bin
$ sudo tar -C /opt/cni/bin -xzf cni-plugins.tgz
また、Linuxオペレーティングシステムの配信が、ブリッジネットワークを介したコンテナトラフィックをiptablesを介してルーティングできるように構成されていることを確認してください。これらの調整は次のように設定できます。
$ echo 1 > /proc/sys/net/bridge/bridge-nf-call-arptables
$ echo 1 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
$ echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables
Nomadクライアントノードの起動時にこれらの設定を保持するには、 /etc/sysctl.d/ sysctl.d/に次のファイルを追加するか、Linux Distributionがそのディレクトリに置いたファイルを削除します。
net.bridge.bridge-nf-call-arptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
Nomadは、静的ポートマッピングと動的ポートマッピングの両方をサポートしています。
静的ポートマッピングはnetworkスタンザに追加できます。
network {
mode = "bridge"
port "lb" {
static = 8889
to = 8889
}
}
ここでは、 hostポート8889 containerポート8889にマッピングされています。
注： systemまたはロードバランサーなどの専門的なジョブを除き、静的ポートは通常推奨されません。
動的ポートマッピングは、 networkスタンザでも有効です。
network {
mode = "bridge"
port "http" {
to = 8080
}
}
ここで、Nomadはhostに動的なポートを割り当て、そのポートはコンテナの8080にマッピングされます。
nomad official documentationでnetwork stanzaの詳細を読むこともできます
Nomadは、一般的なホストのクラスター全体でさまざまなタイプのワークロードをスケジュールします。このため、配置は事前に知られていないため、サービスの発見を使用して、クラスター全体に展開されている他のサービスにタスクを接続する必要があります。 Nomadは領事と統合して、サービスの発見と監視を提供します。
サービスの発見を可能にするために、 serviceをJob Specに追加することができます。
Service Stanzaは、Nomadに領事にサービスを登録するよう指示します。
テストをローカルで実行している場合は、リポジトリで提供されるvagrant VMを使用してください。
$ vagrant up
$ vagrant ssh containerd-linux
$ sudo make test
注：これらは破壊的なテストであり、システムを変更された状態にすることができます。
CI/CDシステムの一部として、CIRCLECIの一部として、またはVagrant VMSなどの不変のインフラストラクチャのいずれかとして、これらのテストを実行することを強くお勧めします。
テスト名を指定して個別のテストを実行することもできます。例えば
$ cd tests
$ sudo ./run_tests.sh 001-test-redis.sh
make clean
これにより、バイナリ： containerd-driverが削除されます
vagrant destroy
これにより、Vagrant VMが破壊されます。
ubuntu（> = 16.04）
Copyright 2020 Roblox Corporation
Apacheライセンス、バージョン2.0（「ライセンス」）に基づいてライセンスされています。詳細については、ライセンスをご覧ください。
