ウェビナーシリーズ:KubernetesでCI / CDを実行するためのビルディングブロック

[。注意]##

ウェビナーシリーズ

この記事はwebinar series on doing CI/CD with Kubernetesを補足します。 このシリーズでは、Kubernetesで使用できるリリース管理、クラウドネイティブツール、サービスメッシュ、CI / CDツールなど、アプリケーションを構築、テスト、デプロイするためのクラウドネイティブアプローチの採用方法について説明します。 CI / CDのベストプラクティスをKubernetesとワークフローに統合することに関心のある開発者や企業を支援するように設計されています。

このチュートリアルには、シリーズの最初のセッションであるKubernetesでCI / CDを実行するためのビルディングブロックの概念とコマンドが含まれています。

前書き

containersを使い始めている場合は、ビルド、テスト、および展開を自動化する方法を知りたいと思うでしょう。 これらのプロセスにCloud Nativeアプローチを採用することで、適切なインフラストラクチャAPIを活用して、アプリケーションを自動化された方法でパッケージ化およびデプロイできます。

自動化を行うための2つの構成要素には、container imagescontainer orchestratorsがあります。 昨年かそこらで、Kubernetesがコンテナオーケストレーションのデフォルトの選択肢になりました。 CI/CD with Kubernetesシリーズのこの最初の記事では、次のことを行います。

  • DockerBuildah、およびKanikoを使用してコンテナーイメージをビルドします。

  • Terraformを使用してKubernetesクラスターをセットアップし、DeploymentsServicesを作成します。

  • Custom Resourcesを使用してKubernetesクラスターの機能を拡張します。

このチュートリアルの終わりまでに、Docker、Buildah、およびKanikoで構築されたコンテナーイメージと、展開、サービス、およびカスタムリソースを含むKubernetesクラスターが作成されます。

このシリーズの今後の記事では、Kubernetesのパッケージ管理、Jenkins XSpinnakerなどのCI / CDツール、サービスメッシュ、GitOpsなどの関連トピックについて説明します。

前提条件

[[step-1 -—- building-container-images-with-docker-and-buildah]] ==ステップ1—DockerとBuildahを使用してコンテナーイメージを構築する

コンテナイメージは、コンテナの作成と実行に使用できる独自のアプリケーションコード、ランタイム、および依存関係を備えた自己完結型のエンティティです。 さまざまなツールを使用してコンテナーイメージを作成できます。この手順では、DockerとBuildahの2つでコンテナーを構築します。

Dockerfilesを使用したコンテナイメージの構築

Dockerは、コンテナイメージをアセンブルするために必要なコマンドを含むテキストファイルであるDockerfileから指示を読み取ることにより、コンテナイメージを自動的に構築します。 docker image buildコマンドを使用すると、Dockerfileで提供されるコマンドライン命令を実行する自動ビルドを作成できます。 イメージをビルドするときに、Dockerfileでbuild contextも渡します。これには、環境を作成し、コンテナーイメージでアプリケーションを実行するために必要なファイルのセットが含まれています。

通常、Dockerfileとビルドコンテキスト用のプロジェクトフォルダーを作成します。 開始するには、demoというフォルダーを作成します。

mkdir demo
cd demo

次に、demoフォルダー内にDockerfileを作成します。

nano Dockerfile

次のコンテンツをファイルに追加します。

~/demo/Dockerfile

FROM ubuntu:16.04

LABEL MAINTAINER [email protected]

RUN apt-get update \
    && apt-get install -y nginx \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* \
    && echo "daemon off;" >> /etc/nginx/nginx.conf

EXPOSE 80
CMD ["nginx"]

このDockerfileは、Nginxを実行するイメージを構築する一連の命令で構成されています。 ビルドプロセス中、ubuntu:16.04はベースイメージとして機能し、nginxパッケージがインストールされます。 CMD命令を使用して、コンテナの起動時にデフォルトのコマンドになるようにnginxも構成しました。

次に、現在のディレクトリ(。)をビルドコンテキストとして使用して、docker image buildコマンドでコンテナイメージをビルドします。 このコマンドに-tオプションを渡すと、イメージにnkhare/nginx:latestという名前が付けられます。

sudo docker image build -t nkhare/nginx:latest .

次の出力が表示されます。

OutputSending build context to Docker daemon  49.25MB
Step 1/5 : FROM ubuntu:16.04
 ---> 7aa3602ab41e
Step 2/5 : MAINTAINER [email protected]
 ---> Using cache
 ---> 552b90c2ff8d
Step 3/5 : RUN apt-get update     && apt-get install -y nginx     && apt-get clean     && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*     && echo "daemon off;" >> /etc/nginx/nginx.conf
 ---> Using cache
 ---> 6bea966278d8
Step 4/5 : EXPOSE 80
 ---> Using cache
 ---> 8f1c4281309e
Step 5/5 : CMD ["nginx"]
 ---> Using cache
 ---> f545da818f47
Successfully built f545da818f47
Successfully tagged nginx:latest

これで画像が作成されました。 次のコマンドを使用して、Dockerイメージを一覧表示できます。

docker image ls
OutputREPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
nkhare/nginx        latest              4073540cbcec        3 seconds ago       171MB
ubuntu              16.04               7aa3602ab41e        11 days ago

これで、nkhare/nginx:latestイメージを使用してコンテナーを作成できます。

Project Atomic-Buildahを使用したコンテナイメージの構築

Buildahは、Open Container Initiative (OCI)に準拠したイメージをすばやく構築するために、Project Atomicによって開発されたCLIツールです。 OCIは、業界のベストプラクティスを標準化するために、コンテナランタイムとイメージの仕様を提供します。

Buildahは、作業コンテナーまたはDockerfileからイメージを作成できます。 Dockerデーモンなしでユーザースペースに完全にイメージを構築でき、buildlistpushtagなどのイメージ操作を実行できます。 この手順では、ソースからBuildahをコンパイルし、それを使用してコンテナーイメージを作成します。

Buildahをインストールするには、パッケージやパッケージセキュリティなどを管理できるツールなど、必要な依存関係が必要になります。 次のコマンドを実行して、これらのパッケージをインストールします。

 cd
 sudo apt-get install software-properties-common
 sudo add-apt-repository ppa:alexlarsson/flatpak
 sudo add-apt-repository ppa:gophers/archive
 sudo apt-add-repository ppa:projectatomic/ppa
 sudo apt-get update
 sudo apt-get install bats btrfs-tools git libapparmor-dev libdevmapper-dev libglib2.0-dev libgpgme11-dev libostree-dev libseccomp-dev libselinux1-dev skopeo-containers go-md2man

buildahソースコードをコンパイルしてパッケージを作成するため、Goもインストールする必要があります。

sudo apt-get update
sudo curl -O https://storage.googleapis.com/golang/go1.8.linux-amd64.tar.gz
sudo tar -xvf go1.8.linux-amd64.tar.gz
sudo mv go /usr/local
sudo echo 'export PATH=$PATH:/usr/local/go/bin' >> ~/.profile
source ~/.profile
go version

次の出力が表示され、インストールが成功したことが示されます。

Outputgo version go1.8 linux/amd64

これで、runcバイナリとともに、パッケージを作成するためのbuildahソースコードを取得できます。 runcは、OCIコンテナランタイムの実装であり、Buildahコンテナを実行するために使用します。

次のコマンドを実行して、runcbuildahをインストールします。

mkdir ~/buildah
cd ~/buildah
export GOPATH=`pwd`
git clone https://github.com/containers/buildah ./src/github.com/containers/buildah
cd ./src/github.com/containers/buildah
make runc all TAGS="apparmor seccomp"
sudo cp ~/buildah/src/github.com/opencontainers/runc/runc /usr/bin/.
sudo apt install buildah

次に、/etc/containers/registries.confファイルを作成して、コンテナレジストリを構成します。

sudo nano /etc/containers/registries.conf

次のコンテンツをファイルに追加して、レジストリを指定します。

/etc/containers/registries.conf

# This is a system-wide configuration file used to
# keep track of registries for various container backends.
# It adheres to TOML format and does not support recursive
# lists of registries.

# The default location for this configuration file is /etc/containers/registries.conf.

# The only valid categories are: 'registries.search', 'registries.insecure',
# and 'registries.block'.

[registries.search]
registries = ['docker.io', 'registry.fedoraproject.org', 'quay.io', 'registry.access.redhat.com', 'registry.centos.org']

# If you need to access insecure registries, add the registry's fully-qualified name.
# An insecure registry is one that does not have a valid SSL certificate or only does HTTP.
[registries.insecure]
registries = []

# If you need to block pull access from a registry, uncomment the section below
# and add the registries fully-qualified name.
#
# Docker only
[registries.block]
registries = []

registries.conf構成ファイルは、レジストリまたはドメイン部分を含まないイメージ名を完成させるときに参照する必要があるレジストリを指定します。

次に、次のコマンドを実行して、ビルドコンテキストとしてhttps://github.com/do-community/rsvpapp-webinar1リポジトリを使用してイメージをビルドします。 このリポジトリには、関連するDockerfileも含まれています。

sudo buildah build-using-dockerfile -t rsvpapp:buildah github.com/do-community/rsvpapp-webinar1

このコマンドは、https://github.com/do-community/rsvpapp-webinar1リポジトリで使用可能なDockerfilleからrsvpapp:buildahという名前のイメージを作成します。

イメージをリストするには、次のコマンドを使用します。

sudo buildah images

次の出力が表示されます。

OutputIMAGE ID             IMAGE NAME                                               CREATED AT             SIZE
b0c552b8cf64         docker.io/teamcloudyuga/python:alpine                    Sep 30, 2016 04:39     95.3 MB
22121fd251df         localhost/rsvpapp:buildah                                Sep 11, 2018 14:34     114 MB

これらのイメージの1つは、作成したばかりのlocalhost/rsvpapp:buildahです。 もう1つのdocker.io/teamcloudyuga/python:alpineは、Dockerfileのベースイメージです。

イメージを作成したら、Docker Hubにプッシュできます。 これにより、将来使用するために保存できます。 まず、コマンドラインからDocker Hubアカウントにログインする必要があります。

docker login -u your-dockerhub-username -p your-dockerhub-password

ログインが成功すると、Docker Hub資格情報を含むファイル~/.docker/config.jsonが取得されます。 次に、そのファイルをbuildahとともに使用して、イメージをDockerHubにプッシュできます。

たとえば、作成したばかりのイメージをプッシュする場合は、次のコマンドを実行して、authfileとプッシュするイメージを引用します。

sudo buildah push --authfile ~/.docker/config.json rsvpapp:buildah docker://your-dockerhub-username/rsvpapp:buildah

次のコマンドを使用して、結果のイメージをローカルDockerデーモンにプッシュすることもできます。

sudo buildah push rsvpapp:buildah docker-daemon:rsvpapp:buildah

最後に、作成したDockerイメージを見てください。

sudo docker image ls
OutputREPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
rsvpapp             buildah             22121fd251df        4 minutes ago       108MB
nkhare/nginx        latest              01f0982d91b8        17 minutes ago      172MB
ubuntu              16.04               b9e15a5d1e1a        5 days ago          115MB

予想どおり、buildahを使用してエクスポートされた新しいイメージrsvpapp:buildahが表示されます。

DockerとBuildahの2つの異なるツールを使用してコンテナーイメージを構築した経験があります。 次に、Kubernetesでコンテナのクラスターをセットアップする方法について説明します。

[[step-2 -—- setting-up-a-kubernetes-cluster-on-digitalocean-using-kubeadm-and-terraform]] ==ステップ2—kubeadmとTerraformを使用してDigitalOceanでKubernetesクラスターを設定する

DigitalOceanでKubernetesを設定するには、さまざまな方法があります。 たとえば、kubeadmを使用してKubernetesを設定する方法の詳細については、How To Create a Kubernetes Cluster Using Kubeadm on Ubuntu 18.04を参照してください。

このチュートリアルシリーズでは、アプリケーション開発へのクラウドネイティブアプローチの採用について説明しているため、クラスターのセットアップ時にこの方法論を適用します。 具体的には、kubeadmとTerraformを使用してクラスターの作成を自動化します。これは、インフラストラクチャの作成と変更を簡素化するツールです。

個人用アクセストークンを使用して、TerraformでDigitalOceanに接続し、3つのサーバーをプロビジョニングします。 これらのVM内でkubeadmコマンドを実行して、1つのマスターノードと2つのワーカーを含む3ノードのKubernetesクラスターを作成します。

Ubuntuサーバーで、SSH keysのペアを作成します。これにより、VMへのパスワードなしのログインが可能になります。

ssh-keygen -t rsa

次の出力が表示されます。

OutputGenerating public/private rsa key pair.
Enter file in which to save the key (~/.ssh/id_rsa):

ENTERを押して、キーペアをホームディレクトリの~/.sshディレクトリに保存するか、別の宛先を入力します。

次に、次のプロンプトが表示されます。

OutputEnter passphrase (empty for no passphrase):

この場合、パスワードなしでENTERを押すと、ノードへのパスワードなしのログインが有効になります。

キーペアが作成されたことを確認するメッセージが表示されます。

OutputYour identification has been saved in ~/.ssh/id_rsa.
Your public key has been saved in ~/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:lCVaexVBIwHo++NlIxccMW5b6QAJa+ZEr9ogAElUFyY [email protected]
The key's randomart image is:
+---[RSA 2048]----+
|++.E ++o=o*o*o   |
|o   +..=.B = o   |
|.    .* = * o    |
| .   =.o + *     |
|  . . o.S + .    |
|   . +.    .     |
|    . ... =      |
|        o= .     |
|       ...       |
+----[SHA256]-----+

次のコマンドを実行して公開鍵を取得します。これにより、端末に表示されます。

cat ~/.ssh/id_rsa.pub

these directionsに従って、このキーをDigitalOceanアカウントに追加します。

次に、Terraformをインストールします。

sudo apt-get update
sudo apt-get install unzip
wget https://releases.hashicorp.com/terraform/0.11.7/terraform_0.11.7_linux_amd64.zip
unzip terraform_0.11.7_linux_amd64.zip
sudo mv terraform /usr/bin/.
terraform version

Terraformのインストールを確認する出力が表示されます。

OutputTerraform v0.11.7

次に、次のコマンドを実行して、Kubernetesクラスターと通信するCLIツールであるkubectlをインストールし、ユーザーのホームディレクトリに~/.kubeディレクトリを作成します。

sudo apt-get install apt-transport-https
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
sudo touch /etc/apt/sources.list.d/kubernetes.list
echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install kubectl
mkdir -p ~/.kube

~/.kubeディレクトリを作成すると、構成ファイルをこの場所にコピーできます。 このセクションの後半でKubernetesセットアップスクリプトを実行したら、これを行います。 デフォルトでは、kubectl CLIは、クラスターにアクセスするために~/.kubeディレクトリーで構成ファイルを探します。

次に、このチュートリアルのサンプルプロジェクトリポジトリを複製します。これには、インフラストラクチャをセットアップするためのTerraformスクリプトが含まれています。

git clone https://github.com/do-community/k8s-cicd-webinars.git

Terraformスクリプトディレクトリに移動します。

cd k8s-cicd-webinars/webinar1/2-kubernetes/1-Terraform/

SSH公開キーのフィンガープリントを取得します。

ssh-keygen -E md5 -lf ~/.ssh/id_rsa.pub | awk '{print $2}'

次のような出力が表示され、強調表示された部分がキーを表します。

OutputMD5:dd:d1:b7:0f:6d:30:c0:be:ed:ae:c7:b9:b8:4a:df:5e

キーはここに表示されているものとは異なることに注意してください。

Terraformが使用できるように、指紋を環境変数に保存します。

export FINGERPRINT=dd:d1:b7:0f:6d:30:c0:be:ed:ae:c7:b9:b8:4a:df:5e

次に、DOパーソナルアクセストークンをエクスポートします。

export TOKEN=your-do-access-token

次に、~/k8s-cicd-webinars/webinar1/2-kubernetes/1-Terraform/プロジェクトディレクトリを見てください。

ls
Outputcluster.tf  destroy.sh  files outputs.tf  provider.tf  script.sh

このフォルダーには、TerraformでKubernetesクラスターをデプロイするために必要なスクリプトと構成ファイルが含まれています。

script.shスクリプトを実行して、Kubernetesクラスターのセットアップをトリガーします。

./script.sh

スクリプトの実行が完了すると、作成したKubernetesクラスターを使用するようにkubectlが構成されます。

kubectl get nodesを使用してクラスターノードを一覧表示します。

kubectl get nodes
OutputNAME                STATUS    ROLES     AGE       VERSION
k8s-master-node     Ready     master    2m        v1.10.0
k8s-worker-node-1   Ready         1m        v1.10.0
k8s-worker-node-2   Ready         57s       v1.10.0

これで、1つのマスターノードと2つのワーカーノードがReady状態になりました。

Kubernetesクラスターをセットアップすると、コンテナーイメージを構築するための別のオプションKaniko from Googleを探索できるようになります。

[[step-3 -—- building-container-images-with-kaniko]] ==ステップ3—Kanikoを使用してコンテナイメージを構築する

このチュートリアルの前半で、DockerfilesとBuildahを使用してコンテナーイメージを構築しました。 しかし、コンテナイメージをKubernetesで直接構築できるとしたらどうでしょうか。 Kubernetes内でdocker image buildコマンドを実行する方法はいくつかありますが、これはネイティブのKubernetesツールではありません。 イメージをビルドするにはDockerデーモンに依存する必要があり、クラスター内のPodsの1つで実行する必要があります。

Kanikoというツールを使用すると、既存のKubernetesクラスターでDockerfileを使用してコンテナーイメージを構築できます。 この手順では、Kanikoを使用してDockerfileでコンテナーイメージを構築します。 次に、この画像をDocker Hubにプッシュします。

画像をDocker Hubにプッシュするには、Docker Hubの資格情報をKanikoに渡す必要があります。 前の手順では、Docker Hubにログインし、ログイン資格情報を使用して~/.docker/config.jsonファイルを作成しました。 この設定ファイルを使用してKubernetesConfigMapオブジェクトを作成し、Kubernetesクラスタ内に認証情報を保存しましょう。 ConfigMapオブジェクトは、構成パラメーターを保存し、アプリケーションから分離するために使用されます。

~/.docker/config.jsonファイルを使用してdocker-configというConfigMapを作成するには、次のコマンドを実行します。

sudo kubectl create configmap docker-config --from-file=$HOME/.docker/config.json

次に、~/k8s-cicd-webinars/webinar1/2-kubernetes/1-Terraform/ディレクトリにpod-kaniko.ymlというポッド定義ファイルを作成できます(ただし、どこにでも移動できます)。

まず、~/k8s-cicd-webinars/webinar1/2-kubernetes/1-Terraform/ディレクトリにいることを確認します。

cd ~/k8s-cicd-webinars/webinar1/2-kubernetes/1-Terraform/

pod-kaniko.ymlファイルを作成します。

nano pod-kaniko.yml

次のコンテンツをファイルに追加して、Podをデプロイするときに何が起こるかを指定します。 ポッドのargsフィールドのyour-dockerhub-usernameを、必ず独自のDocker Hubユーザー名に置き換えてください。

~/k8s-cicd-webinars/webinar1/2-kubernetes/1-Terraform/pod-kaniko.yaml

apiVersion: v1
kind: Pod
metadata:
  name: kaniko
spec:
  containers:
  - name: kaniko
    image: gcr.io/kaniko-project/executor:latest
    args: ["--dockerfile=./Dockerfile",
            "--context=/tmp/rsvpapp/",
            "--destination=docker.io/your-dockerhub-username/rsvpapp:kaniko",
            "--force" ]
    volumeMounts:
      - name: docker-config
        mountPath: /root/.docker/
      - name: demo
        mountPath: /tmp/rsvpapp
  restartPolicy: Never
  initContainers:
    - image: python
      name: demo
      command: ["/bin/sh"]
      args: ["-c", "git clone https://github.com/do-community/rsvpapp-webinar1.git /tmp/rsvpapp"]
      volumeMounts:
      - name: demo
        mountPath: /tmp/rsvpapp
  restartPolicy: Never
  volumes:
    - name: docker-config
      configMap:
        name: docker-config
    - name: demo
      emptyDir: {}

この構成ファイルは、Podがデプロイされたときに何が起こるかを説明しています。 まず、Init containerは、Dockerファイルhttps://github.com/do-community/rsvpapp-webinar1.gitを含むGitリポジトリをdemoと呼ばれる共有ボリュームに複製します。 Initコンテナは、アプリケーションコンテナの前に実行され、アプリケーションコンテナからの実行が望ましくないユーティリティやその他のタスクの実行に使用できます。 次に、アプリケーションコンテナkanikoは、Dockerfileを使用してイメージをビルドし、ConfigMapボリュームdocker-configに渡した資格情報を使用して、結果のイメージをDockerHubにプッシュします。

kanikoポッドをデプロイするには、次のコマンドを実行します。

kubectl apply -f pod-kaniko.yml

次の確認が表示されます。

Outputpod/kaniko created

ポッドのリストを取得します。

kubectl get pods

次のリストが表示されます。

OutputNAME      READY     STATUS     RESTARTS   AGE
kaniko    0/1       Init:0/1   0          47s

数秒待ってから、kubectl get podsを再度実行してステータスを更新します。

kubectl get pods

以下が表示されます。

OutputNAME      READY     STATUS    RESTARTS   AGE
kaniko    1/1       Running   0          1m

最後に、kubectl get podsをもう一度実行して、最終的なステータスを更新します。

kubectl get pods
OutputNAME      READY     STATUS      RESTARTS   AGE
kaniko    0/1       Completed   0          2m

この一連の出力は、Initコンテナーが実行され、demoボリューム内のGitHubリポジトリーのクローンを作成したことを示しています。 その後、Kanikoのビルドプロセスが実行され、最終的に終了しました。

ポッドのログを確認します。

kubectl logs kaniko

次の出力が表示されます。

Outputtime="2018-08-02T05:01:24Z" level=info msg="appending to multi args docker.io/your-dockerhub-username/rsvpapp:kaniko"
time="2018-08-02T05:01:24Z" level=info msg="Downloading base image nkhare/python:alpine"
.
.
.
ime="2018-08-02T05:01:46Z" level=info msg="Taking snapshot of full filesystem..."
time="2018-08-02T05:01:48Z" level=info msg="cmd: CMD"
time="2018-08-02T05:01:48Z" level=info msg="Replacing CMD in config with [/bin/sh -c python rsvp.py]"
time="2018-08-02T05:01:48Z" level=info msg="Taking snapshot of full filesystem..."
time="2018-08-02T05:01:49Z" level=info msg="No files were changed, appending empty layer to config."
2018/08/02 05:01:51 mounted blob: sha256:bc4d09b6c77b25d6d3891095ef3b0f87fbe90621bff2a333f9b7f242299e0cfd
2018/08/02 05:01:51 mounted blob: sha256:809f49334738c14d17682456fd3629207124c4fad3c28f04618cc154d22e845b
2018/08/02 05:01:51 mounted blob: sha256:c0cb142e43453ebb1f82b905aa472e6e66017efd43872135bc5372e4fac04031
2018/08/02 05:01:51 mounted blob: sha256:606abda6711f8f4b91bbb139f8f0da67866c33378a6dcac958b2ddc54f0befd2
2018/08/02 05:01:52 pushed blob sha256:16d1686835faa5f81d67c0e87eb76eab316e1e9cd85167b292b9fa9434ad56bf
2018/08/02 05:01:53 pushed blob sha256:358d117a9400cee075514a286575d7d6ed86d118621e8b446cbb39cc5a07303b
2018/08/02 05:01:55 pushed blob sha256:5d171e492a9b691a49820bebfc25b29e53f5972ff7f14637975de9b385145e04
2018/08/02 05:01:56 index.docker.io/your-dockerhub-username/rsvpapp:kaniko: digest: sha256:831b214cdb7f8231e55afbba40914402b6c915ef4a0a2b6cbfe9efb223522988 size: 1243

ログから、kanikoコンテナがDockerfileからイメージを構築し、DockerHubアカウントにプッシュしたことがわかります。

これで、Dockerイメージをプルできます。 必ずyour-dockerhub-usernameをDockerHubユーザー名に置き換えてください。

docker pull your-dockerhub-username/rsvpapp:kaniko

プルの確認が表示されます:

Outputkaniko: Pulling from your-dockerhub-username/rsvpapp
c0cb142e4345: Pull complete
bc4d09b6c77b: Pull complete
606abda6711f: Pull complete
809f49334738: Pull complete
358d117a9400: Pull complete
5d171e492a9b: Pull complete
Digest: sha256:831b214cdb7f8231e55afbba40914402b6c915ef4a0a2b6cbfe9efb223522988
Status: Downloaded newer image for your-dockerhub-username/rsvpapp:kaniko

これでKubernetesクラスターが正常に構築され、クラスター内から新しいイメージが作成されました。 DeploymentsServicesの説明に移りましょう。

[[step-4 -—- create-kubernetes-deployments-and-services]] ==ステップ4—Kubernetesデプロイメントとサービスを作成する

KubernetesDeploymentsを使用すると、アプリケーションを実行できます。 展開では、ポッドに必要な状態を指定して、ロールアウト全体の一貫性を確保します。 このステップでは、~/k8s-cicd-webinars/webinar1/2-kubernetes/1-Terraform/ディレクトリにdeployment.ymlというNginxデプロイメントファイルを作成して、Nginxデプロイメントを作成します。

まず、ファイルを開きます。

nano deployment.yml

次の構成をファイルに追加して、Nginx Deploymentを定義します。

~/k8s-cicd-webinars/webinar1/2-kubernetes/1-Terraform/deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

このファイルは、3つのポッドを作成するnginx-deploymentという名前のデプロイメントを定義し、それぞれがポート80nginxコンテナーを実行します。

展開を展開するには、次のコマンドを実行します。

kubectl apply -f deployment.yml

デプロイメントが作成されたことの確認が表示されます。

Outputdeployment.apps/nginx-deployment created

展開を一覧表示します。

kubectl get deployments
OutputNAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3         3         3            3           29s

nginx-deploymentデプロイメントが作成され、ポッドの目的のカウントと現在のカウントが同じであることがわかります:3

デプロイメントが作成したポッドをリストするには、次のコマンドを実行します。

kubectl get pods
OutputNAME                                READY     STATUS      RESTARTS   AGE
kaniko                              0/1       Completed   0          9m
nginx-deployment-75675f5897-nhwsp   1/1       Running     0          1m
nginx-deployment-75675f5897-pxpl9   1/1       Running     0          1m
nginx-deployment-75675f5897-xvf4f   1/1       Running     0          1m

この出力から、必要な数のPodが実行されていることがわかります。

アプリケーションのデプロイを内部および外部に公開するには、ServiceというKubernetesオブジェクトを作成する必要があります。 各サービスは、サービスの公開方法を定義するServiceTypeを指定します。 この例では、NodePort ServiceTypeを使用します。これにより、各ノードの静的ポートでサービスが公開されます。

これを行うには、~/k8s-cicd-webinars/webinar1/2-kubernetes/1-Terrafrom/ディレクトリにファイルservice.ymlを作成します。

nano service.yml

次のコンテンツを追加して、サービスを定義します。

~/k8s-cicd-webinars/webinar1/2-kubernetes/1-Terrafrom/service.yml

kind: Service
apiVersion: v1
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  type: NodePort
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
    nodePort: 30111

これらの設定は、サービスnginx-serviceを定義し、ポッドのポート80をターゲットにすることを指定します。 nodePortは、アプリケーションが外部トラフィックを受け入れるポートを定義します。

サービスをデプロイするには、次のコマンドを実行します。

kubectl apply -f service.yml

確認が表示されます:

Outputservice/nginx-service created

サービスのリスト:

kubectl get service

次のリストが表示されます。

OutputNAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
kubernetes      ClusterIP   10.96.0.1               443/TCP        5h
nginx-service   NodePort    10.100.98.213           80:30111/TCP   7s

サービスnginx-serviceはポート30111で公開されており、ノードの任意のパブリックIPでアクセスできるようになりました。 たとえば、http://node_1_ip:30111またはhttp://node_2_ip:30111に移動すると、Nginxの標準のウェルカムページに移動します。

展開をテストしたら、展開とサービスの両方をクリーンアップできます。

kubectl delete deployment nginx-deployment
kubectl delete service nginx-service

これらのコマンドは、作成した展開とサービスを削除します。

展開とサービスを使用したので、カスタムリソースの作成に進みます。

[[step-5 -—- creating-custom-resources-in-kubernetes]] ==ステップ5—Kubernetesでカスタムリソースを作成する

Kubernetesは、限定されていますが、すぐに使用できる機能と機能を提供します。 ただし、Custom Resources機能を使用して、Kubernetesのオファリングを拡張することは可能です。 Kubernetesでは、resourceはKubernetes APIのエンドポイントであり、APIobjectsのコレクションを格納します。 Podリソースには、たとえばPodオブジェクトのコレクションが含まれます。 カスタムリソースを使用すると、ネットワーク、ストレージなどのカスタムサービスを追加できます。 これらの追加は、いつでも作成または削除できます。

カスタムオブジェクトの作成に加えて、コントロールプレーンでKubernetesControllerコンポーネントのサブコントローラーを使用して、オブジェクトの現在の状態が目的の状態と等しいことを確認することもできます。 Kubernetes Controllerには、指定されたオブジェクト用のサブコントローラーがあります。 たとえば、ReplicaSetは、目的のポッドカウントの一貫性を維持するサブコントローラーです。 カスタムリソースをコントローラーと組み合わせると、真のdeclarative APIが得られ、リソースの目的の状態を指定できます。

この手順では、カスタムリソースと関連オブジェクトを作成します。

カスタムリソースを作成するには、最初に~/k8s-cicd-webinars/webinar1/2-kubernetes/1-Terrafrom/ディレクトリにcrd.ymlというファイルを作成します。

nano crd.yml

次のカスタムリソース定義(CRD)を追加します。

~/k8s-cicd-webinars/webinar1/2-kubernetes/1-Terrafrom/crd.yml

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: webinars.digitalocean.com
spec:
  group: digitalocean.com
  version: v1
  scope: Namespaced
  names:
    plural: webinars
    singular: webinar
    kind: Webinar
    shortNames:
    - wb

crd.ymlで定義されたCRDを展開するには、次のコマンドを実行します。

kubectl create -f crd.yml

リソースが作成されたことの確認が表示されます。

Outputcustomresourcedefinition.apiextensions.k8s.io/webinars.digitalocean.com created

crd.ymlファイルは新しいRESTfulリソースパス/apis/digtialocean.com/v1/namespaces/*/webinarsを作成しました。 CustomResourceDefinitionnamesセクションにリストしたように、webinarswebinarWebinar、およびwbを使用してオブジェクトを参照できるようになりました。 )s。 次のコマンドでRESTfulリソースを確認できます。

kubectl proxy & curl 127.0.0.1:8001/apis/digitalocean.com

[。注意]##

Note:前提条件の初期サーバーセットアップガイドに従った場合、このテストを機能させるには、ポート8001へのトラフィックを許可する必要があります。 次のコマンドを使用して、このポートへのトラフィックを有効にします。

sudo ufw allow 8001

次の出力が表示されます。

OutputHTTP/1.1 200 OK
Content-Length: 238
Content-Type: application/json
Date: Fri, 03 Aug 2018 06:10:12 GMT

{
    "apiVersion": "v1",
    "kind": "APIGroup",
    "name": "digitalocean.com",
    "preferredVersion": {
        "groupVersion": "digitalocean.com/v1",
        "version": "v1"
    },
    "serverAddressByClientCIDRs": null,
    "versions": [
        {
            "groupVersion": "digitalocean.com/v1",
            "version": "v1"
        }
    ]
}

次に、webinar.ymlというファイルを開いて、新しいカスタムリソースを使用するためのオブジェクトを作成します。

nano webinar.yml

次のコンテンツを追加して、オブジェクトを作成します。

~/k8s-cicd-webinars/webinar1/2-kubernetes/1-Terrafrom/webinar.yml

apiVersion: "digitalocean.com/v1"
kind: Webinar
metadata:
  name: webinar1
spec:
  name: webinar
  image: nginx

次のコマンドを実行して、これらの変更をクラスターにプッシュします。

kubectl apply -f webinar.yml

次の出力が表示されます。

Outputwebinar.digitalocean.com/webinar1 created

これで、kubectlを使用してwebinarオブジェクトを管理できます。 例えば:

kubectl get webinar
OutputNAME       CREATED AT
webinar1   21s

これで、webinar1というオブジェクトができました。 コントローラーがあった場合、オブジェクトの作成をインターセプトし、定義された操作を実行していました。

カスタムリソース定義の削除

カスタムリソースのすべてのオブジェクトを削除するには、次のコマンドを使用します。

kubectl delete webinar --all

あなたは見るでしょう:

Outputwebinar.digitalocean.com "webinar1" deleted

カスタムリソース自体を削除します。

kubectl delete crd webinars.digitalocean.com

削除されたという確認が表示されます。

Outputcustomresourcedefinition.apiextensions.k8s.io "webinars.digitalocean.com" deleted

削除後は、curlコマンドで以前にテストしたAPIエンドポイントにアクセスできなくなります。

このシーケンスは、Kubernetesコードを変更せずにKubernetesの機能を拡張する方法の概要です。

[[step-6 -—- deleting-the-kubernetes-cluster]] ==ステップ6—Kubernetesクラスターの削除

Kubernetesクラスター自体を破棄するには、~/k8s-cicd-webinars/webinar1/2-kubernetes/1-Terrafromフォルダーのdestroy.shスクリプトを使用できます。 このディレクトリにいることを確認してください。

cd ~/k8s-cicd-webinars/webinar1/2-kubernetes/1-Terrafrom

スクリプトを実行します。

./destroy.sh

このスクリプトを実行すると、TerraformがDigitalOcean APIと通信し、クラスター内のサーバーを削除できるようになります。

結論

このチュートリアルでは、さまざまなツールを使用してコンテナイメージを作成しました。 これらのイメージを使用すると、任意の環境でコンテナーを作成できます。 また、Terraformを使用してKubernetesクラスターをセットアップし、DeploymentおよびServiceオブジェクトを作成して、アプリケーションをデプロイおよび公開します。 さらに、カスタムリソースを定義してKubernetesの機能を拡張しました。

これで、KubernetesでCI / CD環境を構築するための強固な基盤ができました。これについては、今後の記事で説明します。

Related