ドローンCIの使用
21516 ワード
かなり古風な無人UI -しかし、それはドローンで必要なすべてです.
導入
私たちはDrone CI 我々のプロジェクトでは、数ヶ月間.最近、私のチームの無人のパイプラインに関して大きなリファクタリングをしなければならなかったので、ドローンの構成が私の記憶にかなり新鮮であるということで、私はドローンCIとの私の経験に関してブログ柱を書くことができたと思いました.したがって、ここでは開発者としてドローンCIを使用して私の経験は-あなたがDrooneのCIをインストールする方法のようなsysopsのものを探している場合は、どのように認証を行うには、私はそのものについて書いていない、あなたは公式の無人ドキュメントを読む必要があります.
ドローンCI基本
私はドローンについての講義をするつもりはありませんDrone CI home page しかし、代わりにドローンCIについていくつかの重要な側面について書いてドローンのパイプラインを維持する開発者として私の経験について書いてドローンを使用して日常的にアプリケーションを構築し、展開します.
ドローンはコンテナアーキテクチャを使用します.これはドローン管弦楽団がDockerコンテナで稼働しており、無人パイプラインのすべてのステップがその特定のパイプラインステップのための素晴らしい分離環境を提供する新しいコンテナをトリガーすることを意味します.パイプラインの例を以下に示します:
local featureBranchPattern = "feature/*";
...
local buildApps() = {
name: 'build-apps',
user: user,
...
# Drone pipelines
[
{
kind: 'pipeline',
type:'kubernetes',
name: 'feature-branch',
trigger: {
branch: [featureBranchPattern],
event: ['push'],
},
steps: [
changeRights(),
cleanDirs(),
buildApps(),
startPostgresMinio(),
runTests(),
...
featureBranchPattern 上の例ではbuildApps 上の例では"ブランチコンストラクタ"です.if ). JSONNETは、パイプラインのテンプレート共通の部分に、より良い構成言語を提供します.あなたは基本的に任意のを使用することができますDocker image あなたの無人のステップでは、すなわちDocker Hub (例:Docker Compose image データベースを設定するには、S 3シミュレータ、テストの様々な依存関係など、カスタマイズされたDocker画像、すなわち?Drone Plugins , いくつかの特殊なタスクを行うためにドローンで使用することを意味しますAWS ECR Plugin 画像をビルドし、それらをプッシュするAWS ECR または、独自のカスタムビルドのDocker画像を使用することができます.
Linuxシェルを使用します.bash ) パイプライン・ステップを書くとき.以下の例はドローンパイプラインステップのいくつかの簡単なバッシングを示しています.
local user = 1000;
local buildBoxImage = 'circleci/clojure:openjdk-11-tools-deps-1.10.0.414-node';
local m2Repo = ' -Sdeps \'{:mvn/local-repo "/drone/src/.m2/repository"}\' ';
...
local buildApps() = {
name: 'build-apps',
user: user,
image: buildBoxImage,
commands: [
'echo "Starting step: buildApps *********************"',
'whoami',
'pwd',
'export ALL_BEGIN=$$(date +%s)',
# Start actual jar building
'echo "Building koodisto *********************"',
'export COMMAND_BEGIN=$$(date +%s)',
'cd koodisto',
'export NPM_CONFIG_PREFIX=/drone/src/koodisto/.npm-global',
'export PATH=$PATH:/drone/src/koodisto/.npm-global/bin',
'npm install shadow-cljs',
'npm install',
'echo "css phase..."',
'clj ' + m2Repo + ' -A:css -t target/shadow/prod/resources/public/css',
'echo "frontend phase..."',
'clj ' + m2Repo + ' -A:common:frontend -m shadow.cljs.devtools.cli release app',
'echo "uberjar phase..."',
'clj ' + m2Repo + ' -A:common:backend:uberjar',
'cd ..',
'export END=$$(date +%s)',
'export KOODISTO_DURATION=$$(($${END}-$${COMMAND_BEGIN}))',
'echo Koodisto build duration $$(($$KOODISTO_DURATION / 60)) minutes and $$(($$KOODISTO_DURATION % 60)) seconds',
...
無人パイプラインとステップの開発は、ローカルを使用することができますので、簡単ですdrone exec 自分のワークステーションでパイプラインをシミュレートするには、たとえば.
# Convert .drone.jsonnet to .drone.yml...
drone jsonnet --source .drone.jsonnet --stream --target .drone.yml
# ... and run it.
DRONE_REPO_NAME="testing2" DRONE_BRANCH="testing2" DRONE_COMMIT_SHA="testing2aa2" drone exec --trusted --pipeline feature-branch --env-file=tmp/.env .drone.yml
[build-apps:0] + echo "Starting step: buildApps *********************"
[build-apps:1] Starting step: buildApps *********************
[build-apps:2] + whoami
[build-apps:3] node
[build-apps:4] + pwd
[build-apps:5] /drone/src
[build-apps:6] + export ALL_BEGIN=$(date +%s)
[build-apps:7] + echo "Building koodisto *********************"
[build-apps:8] Building koodisto *********************
[build-apps:9] + export COMMAND_BEGIN=$(date +%s)
[build-apps:10] + cd koodisto
[build-apps:11] + export NPM_CONFIG_PREFIX=/drone/src/koodisto/.npm-global
[build-apps:12] + export PATH=$PATH:/drone/src/koodisto/.npm-global/bin
[build-apps:13] + npm install shadow-cljs
[build-apps:14]
[build-apps:15] > [email protected] install /drone/src/koodisto/node_modules/puppeteer
[build-apps:16] > node install.js
...
無人機パイプラインの間、無人機は、ステップの間で共有される一種の環境を保ちます.例えば、git repoは、すべてのステップ(Dockerコンテナ)に自動的にマウントされるあるディレクトリにチェックされます.この方法では、すべてのコンテナーで同じコードディレクトリ構造を参照することができますし、また、そのディレクトリ構造により永続的なアーティファクト(例えば、構築されたJARファイル)を格納することができます(後述するいくつかの他のステップで)Dockerイメージをビルドして、JAR(前のステップで構築したjar)をDockerイメージに割り当てます.また、いくつかの前のステップでDockerネットワーク(例えばDocker Composeを使用する)を作成し、同じネットワークで実行している他のDockerコンテナを使用して別のステップでテストをスピンすることもできます.
実行テストはドローンでかなり良いです.例:
...
local dockerComposePluginImage = 'docker/compose:1.25.4';
...
local startPostgresMinio() = {
name: 'start-postgres-minio',
image: dockerComposePluginImage,
...
commands: [
'echo "Starting docker-compose: postgres and minio..."',
'docker-compose -p clojure-dc -f infra/docker-compose.yml up -d',
],
};
...
local koodistoTests() = {
name: 'koodisto-tests',
image: dockerComposePluginImage,
...
commands: [
...
'echo "Building koodisto unit test image..."',
'docker build -f koodisto/infra/unit-test/Dockerfile -t ' + koodistoUtImage + ' koodisto',
'echo "Starting testing koodisto..."',
'docker run -u 1000 --name koodisto-unit-test --network clojure-network --env-file infra/.env -v /drone/src:/drone/src ' + koodistoUtImage,
],
};
...
# Drone pipelines
...
steps: [
...
buildApps(),
startPostgresMinio(),
koodistoTests(),
...
観測
この章ではドローンを使用しているときに私が指摘した特別な観察をリストします.
キャッシュ.あなたのドローンエグゼクティブがステップのための一時的なDockerコンテナをスピンして、彼らの仕事がされるとき、それらの容器が死ぬので、キャッシングは少し挑戦するかもしれません.しかし、例えば、ノードモジュール、Mavenのデフラグなどをキャッシュすることができますが、手順を少し実行する必要があります.最も簡単な方法は、作業ディレクトリ内の依存関係をダウンロードして、パイプラインストアの最後に依存関係をダウンロードすることですAWS S3 これらの依存関係を特殊なドローンプラグインを使用して保存できます.AWS S3 Cache ).
ユーザーと権利.Dockerハブからのイメージは、あなたが持ちたいものでないかもしれないいろいろなビルトインユーザーを使います.あなたの実際のCI環境はまた、考慮される必要があるいくつかの他の側面を引き起こすかもしれません.個人的には、いくつかの特定のユーザを使用して、そのユーザを使用するすべての手順を実行する最も簡単な解決策を見つけました.
user 次の例でlocal user = 1000; # => Use this user.
...
local buildBoxImage = 'circleci/clojure:openjdk-11-tools-deps-1.10.0.414-node';
...
local buildApps() = {
name: 'build-apps',
user: user, # => This image provides that user
image: buildBoxImage,
...
local changeRights() = {
name: 'change-rights',
image: 'alpine:3.11',
commands:
[
'adduser -D -H -u 1000 node node', # => This image doesn't provide that user... so, just create it.
'getent passwd | grep node',
'chown -R node /drone/src',
],
...
local changeRights() = {
name: 'change-rights',
image: 'alpine:3.11',
commands:
[
'sleep 100000', # => Stop the world!
'adduser -D -H -u 1000 node node',
[print-time-start-pipeline:3] + echo $MYBUF >> drone-build.log
[change-rights:0] + sleep 100000 # => It stopped here!
λ> whoami
kari
λ> docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
71ca3dd39a37 alpine:3.11 "/bin/sh /usr/drone/…" 16 minutes ago Up 16 minutes sun7x2doztrvwt72j058x9lcn9go3h81
c67686bcdcfb docker:dind "dockerd-entrypoint.…" 16 minutes ago Up 16 minutes 2375-2376/tcp 5hi9nwckg6dtufpg06znzf7l6qyqu1ir
λ> docker exec -it 71 /bin/sh
/drone/src # whoami # => We are in!
root
/drone/src # ls -lah
total 84K
drwxrwxr-x 10 1000 1000 4.0K Aug 26 13:33 .
drwxr-xr-x 3 root root 4.0K Aug 26 13:33 ..
-rw-rw-r-- 1 1000 1000 11.2K Aug 26 13:32 .drone.jsonnet
-rw-rw-r-- 1 1000 1000 10.0K Aug 26 13:32 .drone.yml
drwxrwxr-x 8 1000 1000 4.0K Aug 26 11:11 .git
ジェンキンズとドローンの比較
使用済みJenkins 私のCIサーバとしての前年.私のジェンキンズとドローン経験を比較するとき、私は以下の理由のためにより多くのローンのような種類があります:
シェルスクリプト.上の例で見ることができるように、コンテナの中に簡単なシェルコマンドを使用してパイプラインの手順を記述することができますし、これらの手順で基本的に何かを行う.あなたは“Groovyのようなビットではなく、かなりの言語”を使用する必要はありません、私はあなたが私が意味するものを知っていると思います.
コンテナ.コンテナはあなたのビルドのための良い孤立した場所を提供します、そして、一旦あなたが基本的な無人コンテナベースのアーキテクチャを理解するならば、彼らはデバッグにかなり良いです.Jenkinsビルドをデバッグすることはもちろん簡単です.なぜなら、いつでも
ssh JenkinsサーバへのセッションとJenkins Workplaceディレクトリへの移動とそこでの実験ローカル開発.
drone exec あなたのCIパイプラインを開発する本当の良いツールです.そして、いくつかのプラクティス(例えばすべてのステップで同じユーザ)に従うならば、あなたはあなたのワークステーションで、そして、あなたのチームの無人のサーバーで、全く同じ方法でパイプラインを走らせることができます.いいえUI手間.Jenkinsでいくつかの特定のプラグインを使用したい場合は、もちろんJenkinsをインストールするときにインストールすることができますが、通常はJenkins UIを使用する必要があります.ドローンではすべてのdockerコンテナ、特別な構成です.
結論
ドローンは、ビルドパイプラインを作成するためにかなり異なるアーキテクチャとモデルを提供するさわやかな新しいCIツールです.それを試してみる-私はあなただけのように思うかもしれない!
その作家は働いているMetosin クラウドプロジェクトにおけるクロジュールの使用あなたがフィンランドでClojureプロジェクトを始めることに興味があるならば、または、あなたはフィンランドでClojureトレーニングを得ることに興味があります.
カリマルティラ
Reference
この問題について(ドローンCIの使用), 我々は、より多くの情報をここで見つけました https://dev.to/karimarttila/using-drone-ci-392bテキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol