GitOps-CI / CDを介して仮想マシンテンプレートを自動的に構築します

概要:#

2月にスタートした「テンプレートオートメーションシリーズ」は、一連の記事を通じて複数の仮想マシンテンプレートの自動構築に精通してきましたが、実際のエンタープライズ環境でのテンプレートの数はこれをはるかに上回ります。更新はまだ非常に複雑で面倒です(以前に比べて大幅に改善されていますが)。ここで、GitOpsベースの管理テンプレートを共有して、テンプレートの構築と管理の効率をさらに向上させます。この記事では、GitLab CI / CDを使用してテンプレートの管理を自動化する方法を紹介します。

テンプレートの保存には解決が必要な重要な問題があります。クラウドプラットフォームやその他の自動呼び出しが行われたときにテンプレート名で認識されません。テンプレートが名前だけで更新されると、他のシステムは新しいテンプレートを正しく認識できません。 vCenter 6.5はテンプレートの更新のサポートを開始しました。この機能は発生した問題を解決し、Packerは8月末にこの機能(OVFテンプレート)もサポートします。 vCenterコンテンツライブラリを使用するもう1つの利点があります。コンテンツライブラリはサブスクリプションをサポートします。企業に複数のvCenter環境が含まれている場合は、一度だけ構築する必要があります。

前回の記事では、誰もがテンプレートの作成に慣れています。モバイルデバイスの読み取りエクスペリエンスを向上させるために、このマニュアルでは詳細なテンプレート構成を紹介しません。https://github.com/6547709/gitops-packerにアクセスして直接表示できます。コードと構成。

GitOpsに基づいて、vSphereテンプレート機能を自動的に構築します。

  1. Gitlabを使用してテンプレート構成ファイルを保存します。
  2. Gitlab CI / CDに基づく自動テンプレート構築を実現します。
  3. Git送信レコードに基づくセマンティックバージョン管理(フィート、修正)。バージョン番号は自動的にインクリメントされ、テンプレートのメモに保存されます。
  4. CI / CDタスクを定期的に実行して、テンプレートのバリエーションを実現します。
  5. -latestをサフィックスとして付けたvCenterコンテンツライブラリストレージテンプレートを使用します。
  6. vCenterコンテンツライブラリテンプレートは、ビルドされるたびに自動的に更新され、vRAクラウドプラットフォームまたは他のツールが最新のテンプレートを呼び出すようにIDは変更されません。
  7. すべてのパスワードと構成は、.gitlab-ci.ymlを介して定義されます。
  8. Windows2016 / 2019、Ubuntu1804 / 1910/2004、CentOS7 / 8などの複数のテンプレートを提供します。
  9. すべてのテンプレートの基本的な最適化(対応するテンプレートの自動応答ファイルを参照)。
  10. Windowsテンプレートは、ISOイメージを使用して最新のパッチを統合し、展開時間を短縮します。
  11. vSphere7.0およびPacker1.6.4環境でテスト済み。

関連ツール:#

パッカー:これは、ほぼすべての環境をカバーする、プライベートクラウドとパブリッククラウドをサポートするオープンソースの自動仮想マシンテンプレート構築ツールです。

vSphere:企業のお客様に広く使用されているVMwareエンタープライズレベルの仮想化ソフトウェアは、高い安定性、優れたパフォーマンス、高いセキュリティ、および使いやすさという特徴を備えています。

govc:vSphereのリモート管理を実現するgovmomiベースのcliツールです。

https://github.com/vmware/govmomi

Packer-provisioner-windows-update:packerプラグイン用のWindowsUpdate。

https://github.com/rgl/packer-provisioner-windows-update

Gitlab CI / CD:コード統合で動作するCI / CDツールです。

https://docs.gitlab.com/ee/ci/

Semantic-delivery-gitlab:ミラーリングは、セマンティックバージョン管理を実装するために使用されます。
ハーバー:これは、Packer、Govc、およびGenisoimageの実行に使用されるDockerイメージを格納するプライベートDockerイメージリポジトリです。

https://hub.docker.com/r/hutson/semantic-delivery-gitlab

関連コード:Gitlab CI / CDに必要なすべてのファイルが含まれています。

https://github.com/6547709/gitops-packer

各テンプレートの構成については、過去の記事を参照してください。
CI / CDは状況に応じてさまざまなツールを選択でき、原則は同じです。


環境要件#

ステップの概要#

  1. ローカルミラーを保管するためのハーバーミラー倉庫を建設します。
  2. DockerRunnerモードを使用してGitlabおよびGitlabCI / CD関連の環境をセットアップします。
  3. Gitlabでプロジェクトを作成し、関連するコードをアップロードし、関連する構成を変更します。
  4. 自動ビルドテストを実行します。
  5. Gitlab CI / CDにタイミングタスクを追加します。
  6. 実施する。

Packerコマンドを実行するためのDockerIamgeをビルドします#

該当するツールのアドレスからpacker、govc、windows updateの3つの実行可能ファイルをダウンロードし、Dockerfileと同じディレクトリに保存する必要があります。Dockerfileは次のとおりです。

FROM centos:8
LABEL maintainer="Alex Li <[email protected]>"
ENV PACKER_VERSION=1.6.4
ENV GOVC_VERSION=v0.23.0
ENV GOVC_INSECURE=true
ENV TIME_ZONE Asia/Shanghai
RUN ln -sf /usr/share/zoneinfo/${TIME_ZONE}/etc/localtime
ADD ./govc /usr/bin/
ADD ./packer /usr/bin/
ADD ./packer-provisioner-windows-update /usr/bin
RUN chmod a+x /usr/bin/govc /usr/bin/packer /usr/bin/packer-provisioner-windows-update && yum install -y  genisoimage
WORKDIR /tmp
CMD ["/bin/bash"]

DockerBuildを使用してDockerImageをビルドし、コンテナーウェアハウス(プライベートまたはパブリック)にアップロードします。

docker build -t harbor.corp.local/library/gitops-packer:v1.0.
docker push login harbor.corp.local
docker login -u admin harbor.corp.local
docker push harbor.corp.local/library/gitops-packer:v1.0

Semantic-devlivery-gitlabイメージをハーバー#にアップロードします

docker pull hutson/semantic-delivery-gitlab:9.1.0
docker tag hutson/semantic-delivery-gitlab:9.1.0 harbor.corp.local/library/semantic-delivery-gitlab:9.1.0
docker push harbor.corp.local/library/semantic-delivery-gitlab:9.1.0

Gitlabでアクセストークンを作成する#

  1. 個人アカウントでGitlabにログインします。
  2. ユーザー設定->アクセストークンに移動します。
  3. トークン名、有効期限、選択権限を入力します->パーソナルアクセストークンを作成します。
  4. 使用するトークンを保存します。

プロジェクトを作成し、すべてのコードをウェアハウスに送信します#

詳細な手順はここには記載されていません。以下は、最終的な倉庫コンテンツのスクリーンショットです。

.gitlab-ci.yml構成ファイルを変更します#

このファイルは、Gitlab CI / CDのメイン構成ファイルです。共通の構成パラメーターは、このファイルで定義されています。パッカーおよびオペレーティングシステムの自動応答ファイルを変更する必要はありません。

ヒント1:このマニュアルを読みやすくするために、すべての機密情報もこの構成ファイルで宣言されています。機密情報の漏洩を防ぐために、定義にGitlabプロジェクト変数を使用することを強くお勧めします。
ヒント2:次のコード例は削除されています。Githubから完全なコードを入手してください。

# 環境変数の定義。本番環境で機密性の高い定義(例:パスワード)を構成することはお勧めしません。
variables:
 DOCKER_DRIVER:"overlay2"
 GITLAB_TOKEN:"xxxxxxxxxxxxx"
# packer、govc、genisoimageの実行に使用するDockerイメージを定義します。これらは、事前にビルドする必要があります。
 PACKER_DOCKER_IMAGE:"harbor.corp.local/library/packer-gitops:v1.0"
# テンプレートの作成に使用するvCenter関連の情報を定義します。セキュリティを向上させるために、Gitlabのプロジェクト変数でパスワード部分を定義することをお勧めします。
 VC_SERVER:"vcenter.corp.local"
 VC_USERNAME:"[email protected]"
 VC_PASSWORD:"VMware1!"
 VC_DATACENTER:"Labs-DC02"
 VC_CLUSTER:"DC02-Cluster"
 VC_CONTENT_LIBRARY:"DC02-VM-Templates"
 VC_FOLDER:"Templates"
 VC_DATASTORE:"SSD_DATASTORE"
# VM関連の構成を定義する
 VM_NETWORK:"vlan100"
 VM_CPU:2
 VM_MEM:4096
 VM_DISK:81920
 VM_VIDEO_RAM:16384
 VM_HW_VERSION:17
# インストールCDのストレージパスを定義します。Windowsシステムは、インストールCDに従って自動応答ファイルを調整する必要があります。
# - - - - - コードの一部はここでは省略されており、完全なコードはgithubから取得されます。------ 
 OS_CENTOS8_ISO:"[SSD_DATASTORE 0-ISO/CentOS-8.2.2004-x86_64-dvd1.iso"
 OS_WINDOWS2016_ISO:"[SSD_DATASTORE] 0-ISO/cn_windows_server_2016_vl_x64_dvd.iso"
# CentOS8自動応答CDのストレージパスを定義すると、コンパイルごとに以前のバージョンが自動的に上書きされます。
 OS_CENTOS8_KS_ISO:"[SSD_DATASTORE] 0-ISO/centos8-ks.iso"
 OS_CENTOS8_GUI_KS_ISO:"[SSD_DATASTORE] 0-ISO/centos8-gui-ks.iso"
# VMwareToolsのインストールパスを定義する
 OS_WINDOWS_VMTOOLS:"[SSD_DATASTORE] 0-ISO/VMware-tools-windows-11.1.5.iso"
# pvscsiドライバーを使用してWindowsシステムのパスを定義します。このファイルは、同時に1つのVMでのみマウントできます。Windowsシステムごとに1つのファイルを構成する必要があります。
 OS_WIN2016_DRIVER:"[SSD_DATASTORE] 0-ISO/win2016-pvscsi-Windows8.flp"
# CentOS8自動応答ISOのアップロードに使用されるGOVC環境変数を定義します(ks.cfg)
 GOVC_URL: ${VC_SERVER}
 GOVC_USERNAME: ${VC_USERNAME}
 GOVC_PASSWORD: ${VC_PASSWORD}
# この構成は、Linux rootおよびopsユーザー、WindowsAdministratorおよびopsユーザーのパスワードを定義するために使用されます,セキュリティを向上させるために、Gitlabプロジェクト変数でパスワードを定義することをお勧めします。
 LINUX_SSH_PASSWORD:"VMware1!"
 WINDOWS_PASSWORD:"VMware1!"
# この変数は、仮想マシン名を定義するために使用されます。-最新のものは、vCenterコンテンツライブラリにサフィックスとして保存されます。
 CENTOS8_VM_NAME:"CentOS8"
 WIN2016_VM_NAME:"Win2016"

# Windowsインストールキーを定義し、さまざまなインストールバージョンに従って構成します。
 WIN2016_KEY:"XXXXX-XXXXX-XXXXX-XXXXX-XXXX-XXXX"
 WIN2019_KEY:"XXXXX-XXXXX-XXXXX-XXXXX-XXXX-XXXX"
# CIを定義する/CDステージでは、devliverステージを使用してバージョン番号を生成し、validateステージを使用して、パッカー構成ファイルが正しいかどうかを検証し、ビルドします。-isoステージはCentOS8のISO生成に使用され、共有ストレージに自動的にアップロードされます。ビルドステージはテンプレートの構築、リストに使用されます。-ライブラリステージは、コンテンツライブラリテンプレートを一覧表示するために使用されます。
stages:- deliver
 - validate
 - build-iso
 - build
 - list-library

# セマンティックバージョン管理を採用し、コミットメッセージに基づいてバージョン番号を増やし、リリースドキュメントを生成します。この段階では、パッケージ化と展開は行われず、バージョンタグのみが追加されます。
deliver:
 image:
 name: harbor.corp.local/library/sematic-delivery-gitlab:9.1.0
 entrypoint:[""]
 stage: deliver
 only:- master
 script:- semantic-delivery-gitlab --token ${GITLAB_TOKEN}

# このステージは、パッカー構成ファイルが正しいことを確認するために使用されます。
packer-validate:
 image:
 name: ${PACKER_DOCKER_IMAGE}
 stage: validate
 script:- packer validate ./CentOS8/centos-vsphere.json
 - packer validate ./Win2016/win2016-vsphere.json
 only:- tags
 dependencies:- deliver
# このステージは、CentOS8に必要なISOファイルを作成し、vSphereストレージにアップロードするために使用されます(以前のバージョンを自動的に上書きします)。
# for CentOS8。
CentOS8-ks-iso-build:
 image:
 name: ${PACKER_DOCKER_IMAGE}
 stage: build-iso
 script:- cd CentOS8
 - sed -i 's/__PASSWORD__/'"${LINUX_SSH_PASSWORD}"'/g'./ks.cfg
 - genisoimage -o centos8-ks.iso -V "OEMDRV"./ks.cfg
 - govc datastore.upload -ds ${VC_DATASTORE} centos8-ks.iso 0-ISO/centos8-ks.iso
 only:
 changes:- CentOS8/ks.cfg
# - - - - - コードの一部はここでは省略されており、完全なコードはgithubから取得されます。------ 
# このステージは仮想マシンテンプレートを生成するために使用され、テンプレート名はジョブの変数定義に基づいており、最終的なテンプレートが使用されます-最新が最も接尾辞です。
# for CentOS8。
packer-build-CentOS8:
 image:
 name: ${PACKER_DOCKER_IMAGE}
 stage: build
 variables:
 VM_NAME: ${CENTOS8_VM_NAME}
 script:- cd CentOS8
 - packer build --force centos-vsphere.json
 only:- tags
 dependencies:- packer-validate
# - - - - - コードの一部はここでは省略されており、完全なコードはgithubから取得されます。------ 
# for Windows Server 2016。
packer-build-Win2016:
 image:
 name: ${PACKER_DOCKER_IMAGE}
 stage: build
 variables:
 VM_NAME: ${WIN2016_VM_NAME}
 OS_WINDOWS_DRIVER: ${OS_WIN2016_DRIVER}
 script:- cd Win2016
 - sed -i 's/__PASSWORD__/'"${WINDOWS_PASSWORD}"'/g'./Autounattend.xml
 - sed -i 's/__LICENSEKEY__/'"${WIN2016_KEY}"'/g'./Autounattend.xml
 - packer build --force win2016-vsphere.json
 timeout: 120m
 only:- tags
 dependencies:- packer-validate
# - - - - - コードの一部はここでは省略されており、完全なコードはgithubから取得されます。------ 
# list vcenter content library。
list-content-library:
 image:
 name: ${PACKER_DOCKER_IMAGE}
 stage: list-library
 script:- govc library.info -json ${VC_CONTENT_LIBRARY}/*
 only:
 - tags

標準のgitcommitメッセージ形式#

標準および標準化されたコミットメッセージは、バージョン履歴の読みやすさを保証するだけでなく、各変更の内容と範囲を理解し、リリースページにドキュメントを自動的に生成します。したがって、標準のコミットメッセージの形式と内容を使用することを強くお勧めします。

修正:コードの問題を修正するときにこのフラグを使用します。例:修正:WindowsテンプレートのISOファイルエラーを修復します。バージョン番号の変更:1.0.0-> 1.0.1

feat:新しい機能やテンプレートを追加するときにこのフラグを使用します。例:feat:Photonテンプレートを追加します。バージョン番号の変更:1.0.0-> 1.1.0

[ ciをスキップ] CI / CDを自動的に実行したくない場合は、メッセージにこのマークを追加してください。例:修正:ReadME。[skipci]を更新します。バージョン番号の変更:変更なし

実行プロセスと結果を確認します#

変更が送信されると、Gilab CI / CDは、.gitlab-ci.ymlの構成に基づいてパイプラインを自動的に実行します。プロセス全体は、5つのステップからなる2つのグループに分けられます。

  1. セマンティックバージョン管理を実行し、コードにタグを追加します。
  2. タグに基づいてパッカー構成ファイルの検証を実行します。CentOS8はISO構築、画像構築、およびコンテンツライブラリコンテンツリストに自動的に応答します。

パイプラインの実行プロセスを次の図に示します。8つのテンプレートの自動構築を完了するには25分かかります。

テンプレートの更新を表示するには、vCenterコンテンツライブラリにログインします。

スケジュールされたタスクを追加します#

Gitlab CI / CDプランで、追加が完了した後、次の図に示すように、毎週/毎月のスケジュールされた実行プランを追加します。

[ オプション] Windowsミラー統合最新パッチ#

テンプレート構築のプロセスでは、Windowsの構築に最も長い時間がかかり、場合によっては最大2時間かかります。これにより、Gitlab CI / CDとPackerのタイムアウトメカニズムがトリガーされ、タスクが失敗する場合があります。テンプレート作成の効率を上げ、エラー率を下げるために、テンプレートを最新のパッチで自分でパッケージ化することをお勧めします。以下は、参考のための一般的な製造プロセスです。

  1. DISM ++ツール(中国人製、グラフィカル操作)をダウンロードします。
  2. システムインストールCDをディレクトリ(d:\ win2016-iso)に解凍し、解凍したディレクトリにある\ sources \ install.wimファイルを抽出して、別のディレクトリ(d:\ win2016-iso)にコピーします。
  3. DISM ++ツールを開き、install.wimファイルをロードします。マウントパスは事前に作成する必要があります(d:\ win2016-iso \ mnt);
  4. ロードされたinstall.wimシステムを選択し、セッションを開きます。
  5. システムインストールCDを使用して、システムをインストールし、システムアップデートを実行します。アップデートが完了したら、インストールされているシステムアップデートでインストールされているパッチのバージョン番号を見つけます(プログラムの追加/削除)。
  6. https://www.catalog.update.microsoft.com/ Webサイトにログインし、適切なバージョンに基づいてパッチのmsu形式のファイルをダウンロードし、ディレクトリ(d:\ win2016-iso \ msu)に保存します。
  7. DISM ++ツールページで、コントロールパネル->更新管理->追加(d:\ win2016-iso \ msu)を実行し、インストールを実行して、インストールが完了するのを待ちます(長時間)。
  8. パッチをインストールした後、DISM ++->ファイル->画像として保存(d:\ win2016-iso \ new.wim)して、新しい画像を保存します。
  9. new.wimを使用して、システムインストールディスクの解凍されたディレクトリにあるinstall.wimを置き換えます(名前はinstall.wimである必要があります)。
  10. DISM ++-> Common Tools-> Toolbox-> ISO Generatorで、システムインストールディスクと圧縮ディレクトリを選択してinstall.wimファイルをソースとして置き換え、d:\ win2016-iso \ディレクトリをターゲットとして選択し、新しいCDの名前を指定してタグを追加します。
  11. DISM ++->ファイル->イメージのアンインストール;
  12. 指定されたパッチを含むシステムインストールCDが完成しました。
  13. 新しいISOを共有ストレージにアップロードし、.gitlab-ci.ymlファイルを変更して新しいISOイメージパスを使用します。

ヒント1:DISM ++はシステム更新機能を提供しますが、Windows Serverシステムでは正常ではないように思われるため、パッチを手動で追加することをお勧めします。
ヒント2:DISMツールを使用して、インストールCDにpvscsiドライバーを追加することもできるため、pvscsiドライバーを追加する必要はありません。

実施する#

これまで、vSphere環境のテンプレートGitOpsは、Gitlab CI / CD、Govc、Packerを介して実装されていましたが、将来的には、関連する構成ファイルが変更されている限り、テンプレートの構築が自動的に実行されます。この構築は同時に実行されるため、効率が非常に高くなります。簡単に仕事ができ、幸せに暮らせる。

ソース:

https://www.toutiao.com/i6882207358122983948/

Recommended Posts

GitOps-CI / CDを介して仮想マシンテンプレートを自動的に構築します
003.KVM仮想マシンの展開-CentOS6.8