GITLABを用いたシステム間ソリューションの連続配信-パート8 : ICMを用いたCD
21523 ワード
In this series of articles , インターシステム技術とGITLABでソフトウェア開発に向けていくつかの可能なアプローチを紹介し議論したい.以下のようなトピックをカバーします. GIT 101 GITフロー(開発プロセス) GITLABインストール GITLABワークフロー 連続配送 Gitlabのインストールと設定 GITLAB CI/CD コンテナはなぜ? コンテナインフラ コンテナ使用CD ICMを使ったCD この記事では、システム間クラウドマネージャーとの連続配信を構築します.ICMは、システム間のアイリスに基づくアプリケーションのためのクラウドプロビジョニングと展開ソリューションです.それはあなたが希望の配置構成を定義することができますし、ICMは自動的にそれを提供するでしょう.詳細についてはFirst Look: ICM .
ワークフロー
我々の継続的な配送構成では、 GitLabリポジトリにコードをプッシュする ビルドのイメージ Dockerレジストリに画像を公開する テストサーバーでテストします テストがパスすると、生産サーバに配備されます またはグラフィカルな形式で
ご覧のように、私たちが手動でDockerコンテナを管理するのではなく、ICMを使用することを除いて、それはすべてかなりほとんど同じです.
ICM設定
コンテナのアップグレードを始める前に、それらを準備する必要があります.そのためにはデフォルトを定義する必要があります.定義と定義.我々のアーキテクチャを記述しているJSON.私はこれらの2つのファイルを生のサーバーに提供します、テストサーバーのための定義は同じです、デフォルトはタグとsystemmode値を除いて同じです.
デフォルト.JSON :
テストサーバ定義は ライブサーバの定義は 必要なキーをすべて取得した後、
アイリス.キー GCP .JSON ( Googleクラウドプラットフォームへの配備) ICMを呼び出してインスタンスを設定します.
どうぞICM First Look より詳細なガイド.
ビルド
まず、我々のイメージを構築する必要があります.
私たちのコードは、通常通り、倉庫に保存されます
アイリス.キー
許可キー.代わりに、サーバー上に格納されるのではなく、コンテナビルド中にダウンロードできます.倉庫に保管するのはかなり不安定です.
PWDtxt
デフォルトパスワードを含むファイル.再び、倉庫にそれを格納するのはかなり不安定です.また、別のサーバー上のprod環境をホストしている場合は、別のデフォルトのパスワードを持つことができます.
Img .スクリプト
初期スクリプト、 負荷インストーラ インストーラはアプリケーションの初期化を行います ロードコード
前の例とはいくつか異なる.まず最初に、ICMとしてのOS認証がGitLabの代わりに直接コンテナと対話するのを可能にしていません.第二に、インストーラーマニフェストを使用して、初期化に異なるアプローチを示すアプリケーションを初期化します.インストーラで読むin this article . 最後に、我々は個人のレポとして我々のイメージをDocher Hubに公開します.
インストーラ/グローバル.CLS
インストーラマニフェストは次のようになります.
アプリケーションの名前空間を作成します. アプリケーションコードデータベースを作成します. アプリケーションコードデータベースにコードを読み込みます. ユーザの名前空間へのマップMyAppパッケージ. 2つのWebアプリケーションを作成します. Gitlab CI気象研
では、連続的な配信構成にしましょう.
まず第一にdocker build ベースビルドディレクトリのサブディレクトリのみにアクセスすることができます
次に、最初の端末へのアクセスにはユーザ/パスが必要です.
最後に、Dockerイメージを構築し、適切にタグ付けします.
Dockerfile
DockerイメージをビルドするDockerfile , はい、
まず最初に、我々は倉庫の中で(そして、「秘密の」ディレクトリ)を容器の中にコピーします.
次に、ライセンスキーをmgrディレクトリにコピーします.
パスワードをpwdから値に変更します.txt.pwdに注意してください.txtはこの操作で削除されます.
その後、インスタンスを起動し、loadRange CIを起動します.スクリプトが実行されます.
最後に、Irisインスタンスを停止します.
私が使っていることに注意してくださいGitLab Shell executor Docker Executorではありません.あなたがイメージの中から何かを必要とするとき、Docker Executorは使われます、例えば、あなたはJava ContainerでAndroidアプリケーションを構築していて、APKだけを必要とするだけです.この場合、コンテナ全体を必要とします.したがって、gitlabシェルの実行者を介してDockerコマンドを実行しています.
出版
さて、私たちのイメージをDocker Hubで公開しましょう
ジョブログにはパスワード値も含まれません.
ラン
私たちは私たちのイメージを持っています.次はテストサーバーで実行しましょう.これがスクリプトです.
テスト
いくつかのテストを実行しましょう.
配備する
プロダクションサーバーに配備するのは、テストの展開と同じです.テストが失敗した場合、この段階は実行されません.
ICMはあなたにクラウドインフラストラクチャを提供し、それにサービスを展開するためのシンプルで直感的な方法を提供します.コード(IAC)とコンテナ化された展開としてのインフラストラクチャの利点は、Google、Amazon、Azureのようなパブリッククラウドプラットフォームでの、または、あなたの個人的なVMWare vsphere雲の上でシステム間アイリスに基づくアプリケーションを展開するのを簡単にします.あなたが望むものを定義し、いくつかのコマンドを発行し、ICMは残りを行います.
既にクラウドインフラストラクチャ、コンテナ、またはその両方を使用している場合でも、ICMは劇的に多くのそれ以外のマニュアルステップを自動化することによって、アプリケーションを準備および配備するために必要な時間と労力を減らします.
リンク Code for the article Test project ICM Documentation First Look: ICM
ワークフロー
我々の継続的な配送構成では、
ご覧のように、私たちが手動でDockerコンテナを管理するのではなく、ICMを使用することを除いて、それはすべてかなりほとんど同じです.
ICM設定
コンテナのアップグレードを始める前に、それらを準備する必要があります.そのためにはデフォルトを定義する必要があります.定義と定義.我々のアーキテクチャを記述しているJSON.私はこれらの2つのファイルを生のサーバーに提供します、テストサーバーのための定義は同じです、デフォルトはタグとsystemmode値を除いて同じです.
デフォルト.JSON :
{
"Provider": "GCP",
"Label": "gsdemo2",
"Tag": "LIVE",
"SystemMode": "LIVE",
"DataVolumeSize": "10",
"SSHUser": "sample",
"SSHPublicKey": "/icmdata/ssh/insecure.pub",
"SSHPrivateKey": "/icmdata/ssh/insecure",
"DockerImage": "eduard93/icmdemo:master",
"DockerUsername": "eduard93",
"DockerPassword": "...",
"TLSKeyDir": "/icmdata/tls",
"Credentials": "/icmdata/gcp.json",
"Project": "elebedyu-test",
"MachineType": "n1-standard-1",
"Region": "us-east1",
"Zone": "us-east1-b",
"Image": "rhel-cloud/rhel-7-v20170719",
"ISCPassword": "SYS",
"Mirror": "false"
}
[
{
"Role": "DM",
"Count": "1",
"ISCLicense": "/icmdata/iris.key"
}
]
/icmdata フォルダはホストからマウントされ、/icmdata/test フォルダ/icmdata/live フォルダkeygenSSH.sh /icmdata/ssh
keygenTLS.sh /icmdata/tls
/icmdata :cd /icmdata/test
icm provision
icm run
cd /icmdata/live
icm provision
icm run
どうぞICM First Look より詳細なガイド.
ビルド
まず、我々のイメージを構築する必要があります.
私たちのコードは、通常通り、倉庫に保存されます
gitlab-ci.yml しかし、(セキュリティを高めるために)いくつかのサーバー固有のファイルをビルドサーバーに格納します.アイリス.キー
許可キー.代わりに、サーバー上に格納されるのではなく、コンテナビルド中にダウンロードできます.倉庫に保管するのはかなり不安定です.
PWDtxt
デフォルトパスワードを含むファイル.再び、倉庫にそれを格納するのはかなり不安定です.また、別のサーバー上のprod環境をホストしている場合は、別のデフォルトのパスワードを持つことができます.
Img .スクリプト
初期スクリプト、
set dir = ##class(%File).NormalizeDirectory($system.Util.GetEnviron("CI_PROJECT_DIR"))
do ##class(%SYSTEM.OBJ).Load(dir _ "Installer/Global.cls","cdk")
do ##class(Installer.Global).init()
halt
前の例とはいくつか異なる.まず最初に、ICMとしてのOS認証がGitLabの代わりに直接コンテナと対話するのを可能にしていません.第二に、インストーラーマニフェストを使用して、初期化に異なるアプローチを示すアプリケーションを初期化します.インストーラで読むin this article . 最後に、我々は個人のレポとして我々のイメージをDocher Hubに公開します.
インストーラ/グローバル.CLS
インストーラマニフェストは次のようになります.
<Manifest>
<Log Text="Creating namespace ${Namespace}" Level="0"/>
<Namespace Name="${Namespace}" Create="yes" Code="${Namespace}" Ensemble="" Data="IRISTEMP">
<Configuration>
<Database Name="${Namespace}" Dir="${MGRDIR}/${Namespace}" Create="yes" MountRequired="true" Resource="%DB_${Namespace}" PublicPermissions="RW" MountAtStartup="true"/>
</Configuration>
<Import File="${Dir}MyApp" Recurse="1" Flags="cdk" IgnoreErrors="1" />
</Namespace>
<Log Text="Mapping to USER" Level="0"/>
<Namespace Name="USER" Create="no" Code="USER" Data="USER" Ensemble="0">
<Configuration>
<Log Text="Mapping MyApp package to USER namespace" Level="0"/>
<ClassMapping From="${Namespace}" Package="MyApp"/>
</Configuration>
<CSPApplication Url="/" Directory="${Dir}client" AuthenticationMethods="64" IsNamespaceDefault="false" Grant="%ALL" />
<CSPApplication Url="/myApp" Directory="${Dir}" AuthenticationMethods="64" IsNamespaceDefault="false" Grant="%ALL" />
</Namespace>
</Manifest>
では、連続的な配信構成にしましょう.
build image:
stage: build
tags:
- master
script:
- cp -r /InterSystems/mount ci
- cd ci
- echo 'SuperUser' | cat - pwd.txt load_ci_icm.script > temp.txt
- mv temp.txt load_ci.script
- cd ..
- docker build --build-arg CI_PROJECT_DIR=$CI_PROJECT_DIR -t eduard93/icmdemo:$CI_COMMIT_REF_NAME .
まず第一にdocker build ベースビルドディレクトリのサブディレクトリのみにアクセスすることができます
iris.key , pwd.txt and load_ci_icm.script ) クローン化された倉庫に.次に、最初の端末へのアクセスにはユーザ/パスが必要です.
load_ci.script (これはload_ci.script はBTWです).最後に、Dockerイメージを構築し、適切にタグ付けします.
eduard93/icmdemo:$CI_COMMIT_REF_NAMEどこ$CI_COMMIT_REF_NAME は現在のブランチの名前です.イメージタグの最初の部分はgitlabのプロジェクト名と同じ名前でなければならないので注意してください.したがって、Gitlabレジストリタブ(タグ付けの指示はレジストリタブで利用可能です)で見ることができます.Dockerfile
DockerイメージをビルドするDockerfile , はい、
FROM intersystems/iris:2018.1.1-released
ENV SRC_DIR=/tmp/src
ENV CI_DIR=$SRC_DIR/ci
ENV CI_PROJECT_DIR=$SRC_DIR
COPY ./ $SRC_DIR
RUN cp $CI_DIR/iris.key $ISC_PACKAGE_INSTALLDIR/mgr/ \
&& cp $CI_DIR/GitLab.xml $ISC_PACKAGE_INSTALLDIR/mgr/ \
&& $ISC_PACKAGE_INSTALLDIR/dev/Cloud/ICM/changePassword.sh $CI_DIR/pwd.txt \
&& iris start $ISC_PACKAGE_INSTANCENAME \
&& irissession $ISC_PACKAGE_INSTANCENAME -U%SYS < $CI_DIR/load_ci.script \
&& iris stop $ISC_PACKAGE_INSTANCENAME quietly
まず最初に、我々は倉庫の中で(そして、「秘密の」ディレクトリ)を容器の中にコピーします.
次に、ライセンスキーをmgrディレクトリにコピーします.
パスワードをpwdから値に変更します.txt.pwdに注意してください.txtはこの操作で削除されます.
その後、インスタンスを起動し、loadRange CIを起動します.スクリプトが実行されます.
最後に、Irisインスタンスを停止します.
私が使っていることに注意してくださいGitLab Shell executor Docker Executorではありません.あなたがイメージの中から何かを必要とするとき、Docker Executorは使われます、例えば、あなたはJava ContainerでAndroidアプリケーションを構築していて、APKだけを必要とするだけです.この場合、コンテナ全体を必要とします.したがって、gitlabシェルの実行者を介してDockerコマンドを実行しています.
出版
さて、私たちのイメージをDocker Hubで公開しましょう
publish image:
stage: publish
tags:
- master
script:
- docker login -u eduard93 -p ${DOCKERPASSWORD}
- docker push eduard93/icmdemo:$CI_COMMIT_REF_NAME
${DOCKERPASSWORD} 変数、それはgitlabですsecret variable . gitlab > project > settings > ci/cd >変数に追加できます: ジョブログにはパスワード値も含まれません.
Running with gitlab-runner 10.6.0 (a3543a27)
on icm 82634fd1
Using Shell executor...
Running on docker...
Fetching changes...
Removing ci/
HEAD is now at 8e24591 Add deploy to LIVE
Checking out 8e245910 as master...
Skipping Git submodules setup
$ docker login -u eduard93 -p ${DOCKERPASSWORD}
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
Login Succeeded
$ docker push eduard93/icmdemo:$CI_COMMIT_REF_NAME
The push refers to repository [docker.io/eduard93/icmdemo]
master: digest: sha256:d1612811c11154e77c84f0c08a564a3edeb7ddbbd9b7acb80754fda97f95d101 size: 2620
Job succeeded
ラン
私たちは私たちのイメージを持っています.次はテストサーバーで実行しましょう.これがスクリプトです.
run image:
stage: run
environment:
name: $CI_COMMIT_REF_NAME
tags:
- master
script:
- docker exec icm sh -c "cd /icmdata/test && icm upgrade -image eduard93/icmdemo:$CI_COMMIT_REF_NAME"
docker exec icm sh -c ... はICMコンテナ内で指定したコマンドを実行する.最初に我々モード/icmdata/test 我々のICM展開定義がテストサーバーのために定義されるところ.その後コールicm upgrade 現在のコンテナーを新しいコンテナーに置き換えます.テスト
いくつかのテストを実行しましょう.
test image:
stage: test
tags:
- master
script:
- docker exec icm sh -c "cd /icmdata/test && icm session -namespace USER -command 'do \$classmethod(\"%UnitTest.Manager\",\"RunTest\",\"MyApp/Tests\",\"/nodelete\")' | tee /dev/stderr | grep 'All PASSED' && exit 0 || exit 1"
配備する
プロダクションサーバーに配備するのは、テストの展開と同じです.テストが失敗した場合、この段階は実行されません.
deploy image:
stage: deploy
environment:
name: $CI_COMMIT_REF_NAME
tags:
- master
script:
- docker exec icm sh -c "cd /icmdata/live && icm upgrade -image eduard93/icmdemo:$CI_COMMIT_REF_NAME"
ICMはあなたにクラウドインフラストラクチャを提供し、それにサービスを展開するためのシンプルで直感的な方法を提供します.コード(IAC)とコンテナ化された展開としてのインフラストラクチャの利点は、Google、Amazon、Azureのようなパブリッククラウドプラットフォームでの、または、あなたの個人的なVMWare vsphere雲の上でシステム間アイリスに基づくアプリケーションを展開するのを簡単にします.あなたが望むものを定義し、いくつかのコマンドを発行し、ICMは残りを行います.
既にクラウドインフラストラクチャ、コンテナ、またはその両方を使用している場合でも、ICMは劇的に多くのそれ以外のマニュアルステップを自動化することによって、アプリケーションを準備および配備するために必要な時間と労力を減らします.
リンク
Reference
この問題について(GITLABを用いたシステム間ソリューションの連続配信-パート8 : ICMを用いたCD), 我々は、より多くの情報をここで見つけました https://dev.to/intersystems/continuous-delivery-of-your-intersystems-solution-using-gitlab-part-viii-cd-using-icm-37a4テキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol