ウラルIT局の1つの小規模プロジェクトの例に関するCI / CDパイプライン

アクター（チーム）：開発者-2人、管理者-1人。

この記事では、Ansible、Docker Swarm、Jenkins、Portainerなどのテクノロジーを使用して、美しいWebインターフェースを使用して制御できるCI / CDパイプラインを実装する方法について説明しています。

エントリー

開発者は通常何を望んでいますか？ 彼はお金を考えずに、そして自分の創造性の結果をできるだけ早く見たいと考えています。

一方、より多くのお金を必要とするビジネスがあるため、製品を市場に出すまでの時間を短縮することを常に考えています。 言い換えれば、ビジネスは、MVP（別名、Minimum Viable Product）の買収を新製品または既存製品の更新時にスピードアップすることを夢見ています。

さて、管理者は何を望んでいますか？ そして、管理者は単純な人です。彼はサービスが落ちず、 Kwaku Tanksのプレイに干渉しないことを望んでいます。
人生の真実が示すように、管理者の欲望を実現するために、他のヒーローの夢も彼の力によって実現されなければならないため、ITパーティーの代表者はこれに多くの努力をしました。 多くの場合、DevOps方法論に準拠し、CI / CD（継続的インテグレーションと配信）の原則を実装して、目的を達成することができました。

これは、Urals IT Directorateの小さなプロジェクトで発生しました。このプロジェクトでは、開発者がバージョン管理システムにソースの変更を公開し、テスト環境でアプリケーションの新しいバージョンを自動的に起動するまでの完全なパイプラインを短時間で実装することができました。

パート0。タスクの説明

システム構成

議論の後、チームは次の2層アーキテクチャを選択しました。

• Spring Bootフレームワークに実装されたJavaバックエンドは、さまざまなデータベースや他の企業システムと通信します（簡単、迅速、明確な記述方法のため）。
• フロントエンドは非常に高速に動作するため、NodeJS上にあります（ReactJSはブラウザーインターフェイスです）。

次に、これらのコンポーネントにNGINXサーバーが追加されました。これはNodeJSアプリケーションのフロントエンドです。 その役割は、アプリケーション自体とシステムの他のインフラストラクチャコンポーネント間で要求を分散することでした。これについては、以下で説明します。

チームは何を求めていましたか

新しいプロジェクトに青信号が与えられるとすぐに、最初の技術的タスク、すなわち、新しいプロジェクトを立ち上げるための「機器」の準備が現れました。 すべての参加者にとって、新しいバージョンをサーバーにロールアウトする最大の効率がなければ、プロジェクトの開発は非常に難しいことは明らかだったので、すぐに完全なCI / CDのパスに従うことになりました 私は次のパイプラインを達成したいと思いました。

• 開発者は、変更をバージョン管理システム（git）に公開（コミット）します。
• gitは、必要な属性（たとえば、正しいコミットメッセージフォーマット）の存在、銀行のデザインスタイルの遵守、およびその他の官僚制度について、コミットの内容の最小限の必要なテストを実施します。
• git-serverはweb-hooksのメカニズムを介してJenkins継続的統合サーバーを引き出します。
• Jenkinsは、gitからソースの現在のバージョンをダウンロードし、CI / CDパイプラインを実行する操作を開始します。

1. ソースのコンパイルと初期テスト。
2. Dockerイメージの新しいバージョンを組み立てます（2018年にベアメタルまたは仮想マシンに何かを展開するのは下品です、彼らは理解しません）。
3. Artifactory（バイナリアーティファクトのストレージおよび管理システム、推奨！）で画像を公開します。
4. 更新があまり成功しなかった場合に、サーバー上のアプリケーションの新しいバージョン（またはアプリケーションの「スタック」全体）を前のバージョンに「ロールバック」して再起動する。

フレームワーク

このテーマの人々は、おそらく「クベルネテスやメソス/マラソンのような「生産準備の整った」ソリューションではなく、松葉杖を使用しているのはなぜか」と質問しているでしょう。 同様の質問は非常に合理的であるため、説明したソリューションは次のようなさまざまな理由で使用されたとすぐに言ってください。

• それはより単純です（ずっと簡単です）。
• チーム全体で理解し、管理者を展開する方が簡単でした。

ただし、ソリューションが松葉杖の豊富なファミリに属していることを忘れないでください。近い将来、より標準的なOpenShift + Bambooスタックに移行することを望んでいます。

さらに、この記事はWeb指向のアプリケーションのみに関係し、データがおそらくどこかにあるのにデータがどこかにあり、保存することを考えていない場合のステートレスアーキテクチャの理想的なケースについても説明します。

パート1.ホストシステムでのソフトウェアのインストールと基本構成

チェーン全体の自動化と高い再現性を最大化するために、ホストシステム（VMWare / qemu KVM /クラウド/その他に基づく仮想マシン）は、Ansible構成管理システムを使用して構成することにしました。

簡単な再現性と再現性に加えて、このようなシステム（Ansibleの他に、PuppetとChefシステムもあります）の使用は、various等の形式でのさまざまなシェルまたはpythonスクリプトの使用よりも大きな利点があることを付け加える価値があります。 繰り返し起動してもシステムの最終状態が変わらないプロパティ。

この利点は、構成管理システムを使用する場合、記述されるのは望ましい状態を達成するプロセスではなく、宣言的な形での望ましい状態自体であるという事実に由来します。

1.1 ssh HostKeyChecking

デフォルトでは、Ansibleはセキュリティを尊重し、リモート設定可能ホストのsshフィンガープリントを検証します。 なぜなら このモードでは、パスワードで認証する機能が無効になります。その後、サーバーの初期セットアップでHostKeyCheckingを無効にするか、最初にローカルキャッシュに指紋を追加する必要があります。 後者は2つの方法で実現できます。

または：

特別な環境変数を定義します。

$ export ANSIBLE_HOST_KEY_CHECKING=False 

または別の方法で：

host_key_checkingパラメーターをローカルのansible.cfg構成ファイルに追加します。

 [defaults] host_key_checking = False 

最初の方法では、このような環境変数が存在する間のみチェックが無効になり、2番目の方法ではこのホストに対して完全に無効になります。

1.2インベントリ

インベントリは、設定を制御する必要があるホストとそのグループを記述するAnsibleシステムのエンティティです。

インベントリは、iniまたはyaml形式で記述できます。 このプロジェクトでは、最後のプロジェクトが選択されました。

hosts.ymlファイルの例：

 #_  all   all: hosts: #    ,     Ansible some-cool-vm-host vars: #  ,    ansible_user: 'root' #    ,       :-( ansible_password: '12345678' #     corp_ca_crt: "-----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----" 

yaml形式に初めて直面したとき、この形式のすべてのインデントはスペースで埋めなければならないことに注意したいと思います。

1.3プレイブック

PlaybookはAnsibleの別のエンティティであり、Inventoryからホストとグループの望ましい最終状態を宣言的に直接記述します。 Ansibleのほとんどすべてのものと同様に、プレイブックはyaml形式のファイルで記述されます。

プレイブックファイルを実行するには、次の形式のコマンドを実行する必要があります。

 ansible-playbook -i ./hosts.yml tasks.yml 

このプレイブックでは、必要なユーザーの作成とDockerのインストールを含む基本システムの完全なセットアップについて説明しました。

 #_      ,       () - hosts: all tasks: #   - name:      shell: rm /etc/zypp/repos.d/* || exit 0 - name:   SLES-   REPOs... zypper_repository: repo="{{ item.repo }}" name="{{ item.name }}" disable_gpg_check="{{ item.disable_gpg_check|default('no') }}" with_items: - { repo: "http://...", name: "SLE-DISTRO-X" } - name:       zypper: name: '*' state: latest - name:    CA   copy: #     Inventory content: '{{ corp_ca_crt }}' dest: /etc/pki/trust/anchors/orpCA.crt owner: root group: root mode: 0644 - name: ...     shell: update-ca-certificates - name:     group: name="{{ item.name }}" gid={{ item.gid }} state="present" with_items: - { name: "docker", gid: 1000 } - user: name: "{{ item.name }}" uid: "{{ item.uid }}" group: "{{ item.gid }}" state: "present" with_items: - { name: "dockeradm", uid: 1000, gid: "docker" } - name:    user: name: "{{ item }}" password: "$6$..." generate_ssh_key: yes with_items: - root - dockeradm - name:   ssh-          authorized_key: user: "{{ item }}" key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}" state: "present" with_items: - root - dockeradm - name:   VG   lvg: vg: 'vgAPP' pvs: '/dev/sdb' - name: ...  LV lvol: vg: "{{ item.vg }}" lv: "{{ item.lv }}" size: "{{ item.size }}" with_items: - { vg: 'vgAPP', lv: "lvData", size: "10G" } - { vg: 'vgAPP', lv: "lvDockerData", size: "5G" } - name:     LV- filesystem: dev="/dev/{{ item }}" fstype="btrfs" with_items: - 'vgAPP/lvData' - 'vgAPP/lvDockerData' - name:      /etc/fstab    mount: path="{{ item.dst }}" src="/dev/{{ item.src }}" state="mounted" fstype="btrfs" opts="noatime" with_items: - { src: "vgAPP/lvData", dst: "/APP" } - { src: "vgAPP/lvDockerData", dst: "/var/lib/docker" } - name:     file: path: "{{ item.path }}" state: "directory" #     mode: "0{{ item.perms|default('755') }}" owner: "{{ item.user|default('dockeradm') }}" group: "{{ item.group|default('docker') }}" with_items: - { path: '/etc/docker', user: 'root', group: 'root' } - { path: '/APP' } - { path: '/APP/configs' } - { path: '/APP/configs/filebeat' } - { path: '/APP/logs' } - { path: '/APP/logs/nginx' } - { path: '/APP/jenkins' } - { path: '/APP/jenkins/master' } - { path: '/APP/jenkins/node' } - { path: '/APP/portainer_data' } - name:      zypper: name: '{{ item }}' with_items: - docker - mc # Java    Jenkins- - java-1_8_0-openjdk-headless #        - name:  -  " " template: src: daemon.json dest: /etc/docker/daemon.json owner: root group: root mode: 0644 - name:    ... systemd: name: "{{ item }}" state: 'restarted' enabled: 'yes' with_items: - docker - sshd - name:     docker-compose     get_url: url: "https://github.com/docker/compose/releases/download/1.18.0/docker-compose-Linux-x86_64" dest: "/tmp/docker-compose" delegate_to: 127.0.0.1 - copy: src: "/tmp/docker-compose" dest: "/usr/local/bin/docker-compose" mode: "u=rwx,g=rx,o=rx" - name:  - NGINX,     template: src: nginx.conf dest: /APP/configs/nginx.conf owner: dockeradm group: docker mode: '0644' - name:   docker-compose - ,     template: src: docker-compose.yml dest: /APP/docker-compose.yml owner: dockeradm group: docker mode: '0644' - name:  docker-compose -   Jenkins, Portainer  NGINX   shell: docker-compose -f /APP/docker-compose.yml up -d --force-recreate - name:    Jenkins- wait_for: path: '/APP/jenkins/master/secrets/initialAdminPassword' - name:     Jenkins fetch: src: '/APP/jenkins/master/secrets/initialAdminPassword' dest: initialJenkinsAdminPassword.txt flat: yes 

パート2.プロジェクトサービス

2.1 CIサーバーとプロセス

有名なJenkins CIサーバーは、プロジェクトの「継続的な統合と展開」のプロセスを担当します。

上記のAnsibleプレイブックコードは、実行の最後に、新しくインストールされたJenkinsがサーバー（Dockerコンテナー内）で既に実行され、その一時パスワードがinitialJenkinsAdminPassword.txtファイルのLOCALマシンに保存されるように設計されています。

チーム全体がコードとしてのインフラストラクチャ（IaC）の理想的なケースにできるだけ近づけることを望んでいたため、プロジェクトのタスクは、Groovyスクリプト言語でタスクが記述され、そのコードがプロジェクトソースの隣に格納されている場合、 宣言およびスクリプト化された Jenkinsパイプラインの形式で実装されましたバージョン管理システム（git）。

Spring Bootでアプリケーションのバックエンド部分を組み立てるためのパイプラインの例を以下に示します。

 pipeline { agent { # ,      # Docker-    : docker { image 'java:8-jdk' } } stages { stage('   ') { steps { checkout scm } } stage('') { steps { sh 'chmod +x ./gradlew' sh './gradlew build -x test' } } stage('') { steps { script { sh './gradlew test' } } } } } #_    Docker-      Artifactory: node { stage(' ') { docker.withRegistry("https://repo.artifactory.bank", "LoginToArtifactory") { def dkrImg = docker.build("repo.artifactory.bank/dev-backend:${env.BUILD_ID}") dkrImg.push() dkrImg.push('latest') } } stage('   Artifactory') { docker.withRegistry("https://repo.artifactory.bank", "LoginToArtifactory") { sh "docker service update --image repo.artifactory.bank/dev-backend:${env.BUILD_ID} SMB_dev-backend" } } } 

画像を組み立てるときに、各バージョンが独自のタグ（ラベル）を取得するため、アプリケーションの自動再起動プロセスが大幅に容易になることに注意してください。

2.2ポーテイナー

プロジェクトのすべてのチームメンバーとDockerの相互作用を促進するために、単純なWebインターフェースであるPortainerを使用しました。 このアプリケーションは、Docker自体と同様にGoで記述されているため、非常に簡単に展開できる高いパフォーマンスが特徴です。

たとえば、最も単純な場合、次のコマンドはホストシステムのポート9000でPorteinerを起動します。

 docker run -d \ -p 9000:9000 \ -v /var/run/docker.sock:/var/run/docker.sock \ portainer/portainer 

ただし、現在のプロジェクトでは、1つのホスト（ Docker Compose）に対して「オーケストレーション」ツールの機能を使用することが決定されました。

2.3 Dockerコンテナーとサービス

このプロジェクトで必要なすべてのアプリケーションとサービスは、単純なdocker-compose.ymlファイルを介して起動されます。

「インフラストラクチャ」サービスの基本セットは、次の説明を通じて開始されます。

 version: '3.4' services: #     NGINX nginx: image: "nginx:1" container_name: fe-nginx restart: always volumes: - /APP/configs/nginx.conf:/etc/nginx/nginx.conf - /APP/logs/nginx:/var/log/nginx - /usr/share/zoneinfo/Europe/Moscow:/etc/localtime:ro networks: - int ports: - "80:80/tcp" - "8080:80/tcp" # Jenkins CI - ,    CI/CD- ci: image: "jenkins/jenkins:lts" container_name: ci-jenkins restart: always volumes: - /usr/share/zoneinfo/Europe/Moscow:/etc/localtime:ro - /APP/jenkins/master:/var/jenkins_home environment: JENKINS_OPTS: '--prefix=/jenkinsci' JAVA_OPTS: '-Xmx512m' networks: int: aliases: - srv-ci # -  Docker- portainer: image: "portainer/portainer:latest" volumes: - type: bind source: /var/run/docker.sock target: /var/run/docker.sock - type: bind source: /APP/portainer_data target: /data networks: int: aliases: - srv-portainer command: -H 'unix:///var/run/docker.sock' networks: int: external: true 

2.4クラスターなしのDocker Swarmクラスター

上記のdocker-compose.ymlファイルを見るとわかるように、まず、アプリケーションのバックエンド部分とフロントエンド部分への参照がなく、intという名前の「外部」（外部：true）ネットワークへのリンクもあります。 外部リソースとは、単一のファイルで宣言されていないリソース（ネットワーク、ボリューム、およびその他の既存のエンティティ）です。

実際のところ、プロジェクトでは、Artifactory Dockerリポジトリ内のイメージのバージョンを更新するときに「サービス」を再起動できる必要があり、同様の機能がDocker Swarmサービス（Dockerコンテナ用のDockerマルチマスター組み込みオーケストレーションシステム）に存在し、箱から出して。」 この機能は、実行中のサービスの必要なイメージを変更する機能を通じて実装され、リポジトリにイメージの新しいバージョンがある場合、再起動は自動的に行われます。 バージョンが変更されていない場合、サービスコンテナは引き続き正常に実行されます。

ネットワークについては、Docker Swarmサービスの形式でアプリケーションを起動するときに（yamlの説明を以下に示します）、上記で発表したコンポーネントとNGINXサーバーのネットワーク接続を維持する必要がありました。 これは、上記の基本サービスとアプリケーションコンポーネント自体の両方を含むサーバークラスター上にオーバーレイネットワークを作成することで実現しました。

 docker network create -d overlay --subnet 10.1.2.254/24 --attachable int 

（-それがなければ、基本サービスはクラスターネットワークにアクセスできないため、接続可能が必要です）

2つのサービスを備えたアプリケーションコンポーネントの説明：

 version: '3.2' services: pre-live-backend: image:repo.artifactory.bank/dev-backend:latest deploy: mode: replicated replicas: 1 networks: - int pre-live-front: image: repo.artifactory.bank/dev-front:latest deploy: mode: replicated replicas: 1 networks: - int networks: int: external: true 

おわりに

冒頭で述べたように、プロジェクトの開始時に、チームはDevOpsアプローチのすべての利点を取得したいと考えていました。特に、Gitリポジトリから実行中のアプリケーションとして「バトル」サーバーにコードを継続的に配信するプロセスを整理したいと考えていました。 同時に、現在の段階では、確立された慣行を完全に放棄し、大規模なオーケストレーターの世界での生活の中で自分自身を再構築したくありませんでした。 説明されたシステムアーキテクチャは、2週間未満で（チームメンバーが取り組んでいた他のプロジェクトと並行して）考え出されて実装され、最終的に私たちが望むものを達成することができました。 この資料は、DevOpsアプローチを実装する他のチームにとって興味深く有用であると考えています。