What's New Qiita

20201122のdockerに関する記事は13件です。

  • 投稿日：2020-11-22T22:54:47+09:00

Windows 10 HomeでOpenDroneMapを動かしSfMを作成する

はじめに

ドローンで撮影した大量の画像を入手いたしました。

撮影画像をつなぎ合わせてデジタル3Dモデルを構築する、SfM (Structure from Motion)処理を行うためには、スイスPix4D社のソフトウェアなどが利用されています。

しかし、Pix4d Mapperなどの有償ソフトウェアは大変高額で、フリーソフトでデジタル3Dモデルを構築できないか挑戦してみました。

Open Drone MapとWebODM

フリーソフトウェアとしてOpen Drone Map、そしてその後継であるWebODMというソフトウェアが利用できます。今回は、WebODMをインストールします。

Docker for Windowsの利用

WebODMを動作させるためには、Dockerコンテナ環境の導入が必要になります。

従来、Windows 10 Proなど、Hyper-Vハイパーバイザを利用できるOSバージョンであれば、Docker for Windowsが動作するのですが、多くの家庭で使われているWindows 10 Homeでは、Hyper-Vが使えず、Docker for Windowsを利用できませんでした。そのため、Oracle Virtualboxなどの仮想化ソリューションとDocker Toolboxとの組み合わせを利用する、などでWindows 10 HomeでのDocker環境が実現されていたようです。

しかし今年に入って、Windows 20H1(2004)バージョンからWSL 2(Windows Subsystem for Linux 2)の仮想化環境がMicrosoftの仮想化ソリューションとして準備されるようになりました。そのため、WSL2環境を導入することで、Docker for Windowsを動作させられるようになります。

このため、2019年頃に書かれたドキュメント類であってもすでに情報としては古くなっているものが多いです。

導入手順

Windows 10 HomeにWSL2を導入する

  • Docker ToolboxやVirtualBoxが入っていたらアンインストールします。
  • WSL2をインストールします。ディストリビューションには、Ubuntu 20 LTSを選択しました。

Docker, Git, Python3のインストール

下記のWindowsクライアントをインストールします。
- Docker Desktop for Windows
- Git Gui Client
- Python 3.9.0 Add Python 3.9 to PATHにチェックします。

WebODMのインストール

WebODMのInstallation and Getting Startedに従ってインストールしていきます。
- Git Guiを開き、Clone Existing Repositoryを選択します。
- Source Locationに、https://github.com/OpenDroneMap/WebODM と入力します。
- Target Directoryにて、処理対象のフォルダと、作業用フォルダを指定します。
- Cloneを選択します。
- Repository menuからCreate Desktop Iconを選択してデスクトップアイコンを作ります。

WebODMを使う

  • Git GuiのRepository menuから、Git Bashを選択します。
  • Bashターミナルに$ ./webodm.sh start&と入力してWebODMをスタートさせます。
  • ブラウザを開き、http://localhost:8000 を開きます。
  • WebODMを終了する際は、./webodm.sh stopと入力します。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-11-22T22:54:47+09:00

Windows 10でWebODMを動かしSfMの点群データ・オルソモザイク画像を生成する

はじめに

ドローンで撮影した大量の画像を入手いたしました。

撮影画像をつなぎ合わせてデジタル3Dモデルを構築する、いわゆるSfM (Structure from Motion) 処理を行うためには、一般的にはスイスPix4D社のPix4D Mapperなどが利用されています。しかし、メジャーなSfMソフトウェアは大変高額であり、フリーソフトでデジタル3Dモデルを構築できないか挑戦してみました。

Open Drone MapとWebODM

SfMを行うために、Open Drone Map、そしてそのUIであるWebODMといったソフトウェアが無料で利用できます。今回はこのWebODMをインストールします。

Docker Desktop for Windowsの利用

WebODMを動作させるためには、Dockerコンテナ環境の導入が必要になります。

従来Docker for Windowsを動かすためには、Windows 10 ProなどHyper-Vハイパーバイザを利用できるOSバージョンが必要でした。Windows 10 HomeではHyper-Vが使えないため、代替策としてOracle VM Virtualboxなどの仮想化ソリューションとDocker Toolboxとの組み合わせを利用するなどが用いられていたようです。

しかし今年に入って、Windows 20H1(2004)バージョンからWSL 2 (Windows Subsystem for Linux 2) 仮想化環境が利用できるようになりました。このWSL2環境を導入することで、Windows 10 Home環境でもDocker ToolboxではなくDocker Desktop for Windowsを動作させられるようになります。

2019年頃に書かれたドキュメント類には、Docker Toolboxの利用について解説してある記事などが多く、WSL2によるWebODM環境の構築を説明したページは見つけることができませんでしたのでこのエントリを書くことにしました。Docker Toolboxはすでに開発を終えているので、本手順での環境構築をおすすめします。

導入手順

Windows 10 HomeにWSL2を導入する

  • Docker ToolboxやVirtualBoxが入っていたらアンインストールします。
  • WSL2をインストールします。ディストリビューションには、Ubuntu 20.04 LTSを選択しました。

Docker Desktop, Git, Python3のインストール

下記のWindowsクライアントをインストールします。
- Docker Desktop for Windows
- Git Gui Client
- Python 3.9.0 Add Python 3.9 to PATHにチェックします。

WebODMのインストール

WebODMのInstallation and Getting Startedに従ってインストールしていきます。
- Git Guiを開き、Clone Existing Repositoryを選択します。
- Source Locationに、https://github.com/OpenDroneMap/WebODM と入力します。
- Target Directoryにて、ターゲットフォルダを指定します。pic3.png
- Cloneを選択します。
- Repository menuからCreate Desktop Iconを選択してデスクトップアイコンを作ります。

WebODMを使う

  • Git GuiのRepository menuから、Git Bashを選択します。
  • Bashターミナルに$ ./webodm.sh start&と入力してWebODMをスタートさせます。初回起動時には、不足しているソフトウェアのインストールが自動的に行われます。pic4.png
  • ブラウザを開き、http://localhost:8000 を開きます。
  • ユーザ名とパスワードを入れると、WebODMの管理画面になります。pic11.png
  • 撮影画像を読み込ませると、点群データやオルソモザイク画像などを出力できるようになります（下の画像は点群データではなく、モザイク処理を施してあります）。 pic17-s.png
  • WebODMを終了する際は、./webodm.sh stopと入力します。

追記1：仮想ディスクの場所を変更する

データ処理の途中で起動ドライブであるSSDが溢れてしまったので、対処します。

Docker Desktop for Windowsでは、標準ではCドライブに仮想ディスク領域（.vhdx形式）を作成しますが、これを別の物理ディスクであるDドライブ（HDD）に移動します。

  • Docker Desktopのタスクトレイ アイコンからQuit Docker Desktopを選びDockerを停止させます。
  • Windows PowerShell（管理者モード）にて下記コマンドを実行し、ディスクを移動させます。
> wsl --shutdown 
> wsl --export docker-desktop-data D:\opt\Docker\docker-desktop-data.tar
> wsl --unregister docker-desktop-data
> wsl --import docker-desktop-data D:\opt\Docker D:\opt\Docker\docker-desktop-data.tar
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-11-22T21:38:36+09:00

GitHub Container Registry(ghcr.io)のPrivateイメージをKubernetesで使う

結論

imagePullSecretsを利用する．

プライベートレジストリを使用する方法 - イメージ | Kubernetes

方法

(1) imagePullSecretsの登録

プライベートイメージをPullするときに使うシークレット(imagePullSecrets)を登録する．

今回は以下のリンク先にある既存Docker用設定ファイルを流用する方法を使った．

GitHub Container Registryのセットアップ方法は過去の記事にある．

Pull an Image from a Private Registry | Kubernetes

~/.docker/config.json
{
        "auths": {
                "https://index.docker.io/v1/": {
                        "auth": "xxxxxxxxxxxxxxxxx"
                },
                "ghcr.io": {
                        "auth": "xxxxxxxxxxxxxxxxx"
                }
        }
}

手元のマシンで以下のコマンドを実行してYAMLを生成した．

kubectl create secret generic regcred \
    --from-file=.dockerconfigjson=~/.docker/config.json \
    --type=kubernetes.io/dockerconfigjson --dry-run=client -o yaml

コマンドの実行結果

ghcr.yaml
apiVersion: v1
data:
  .dockerconfigjson: XXX
kind: Secret
metadata:
  creationTimestamp: null
  name: regcred
type: kubernetes.io/dockerconfigjson

YAMLの中身をリモートにコピーしてデプロイする．

kubectl apply -f ghcr.yaml

(2) imagePullSecretsをDeploymentに追記

以下を参考にDeploymentに imagePullSecrets を記述する．

dep.yaml
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      imagePullSecrets:
        - name: regcred
# 略

kubectlコマンドでデプロイする．

kubectl apply -f dep.yaml

おわりに

プライベートレジストリも慣れれば簡単にPullできるので，この機会に利用していきたい．

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-11-22T21:17:27+09:00

【Docker】postgres,pgadmin4環境構築

はじめに

dockerでpostgres,pgadmin4環境構築する方法をメモ

環境情報

  • OS：Redhat 7.7
  • Docker：19.03.6-ce
  • docker-compose：1.27.4

docker-compose.yml

version: '3'

services:
  pgadmin4:
    build: pgadmin4
    container_name: pgadmin4
    volumes:
      - pgadmin4_data:/var/lib/pgadmin
    environment:
      - PGADMIN_DEFAULT_EMAIL=【初期ログインアドレス】
      - PGADMIN_DEFAULT_PASSWORD=【初期ログインパスワード】
    ports:
      - "80:80"

  postgres:
    image: postgres:latest
    container_name: postgres
    volumes:
      - postgres_data:/var/lib/postgresql/data
    environment:
      - POSTGRES_USER=【ユーザー】
      - POSTGRES_PASSWORD=【パスワード】
      - POSTGRES_INITDB_ARGS=--encoding=UTF-8 --locale=C
      - TZ=Asia/Tokyo
    ports:
      - 5432:5432

volumes:
  pgadmin4_data:
    external:
      name: pgadmin4_data
  postgres_data:
    external:
      name: postgres_data

Dockerfile

FROM dpage/pgadmin4

USER root

RUN apk update \
    && apk add --update --no-cache tzdata \
    && cp /usr/share/zoneinfo/Asia/Tokyo /etc/localtime \
    && echo "Asia/Tokyo" > /etc/timezone \
    && apk del tzdata

EXPOSE 80
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-11-22T20:42:28+09:00

Windows10でDockerをインストールしてCentOS8の検証環境を作るところまでやってみましょい！

何でDocker使おうと思ったんだい？

自宅サーバーのCentOS8君の検証環境を作りたかったのじゃ…。
流石に『いきなり本番で実行！』はちょっとね…(´・ω・`)

Redmineのインストールで相当手ごずって『これは検証機が欲しいねえ…』と切に思った次第。

まずはインストール

Docker Desktop のページからインストーラをダウンロード！（stable = 安定版 にしたよ）
image.png
インストーラー起動！
よく分からんかったらひとまず全部入れとけってばっちゃが言ってた。
image.png
今回入れるDocker Desktopのバージョンは2.5.0.1（49550）ですね。
あとはただお茶でも飲んで待ってればOK！
下図のrestartはOSの再起動だから注意ね！
image.png
Docker動かす上で必要なものがちょっと抜けてるからインストールして再起動して！って言ってくる。
image.png
リンク先のWindowsのページでカーネル更新プログラムパッケージをダウンロード。
image.png
カーネル更新プログラムパッケージを起動！
image.png
特に問題も無くインストール終了！
image.png
んでんでんで、Dockerの方を再起動
image.png
チュートリアル画面が出てくればインストール終了！
image.png

チュートリアルはスキップ

チュートリアルは一応やってみたけど、ガチでDocker初心者のあたいにとってはただボタンポチポチ押すだけのものだった。

Docker ID 取得

Docker イメージ（≒ 他の人がもう作ってくれた環境）をもらえるようにDocker IDを取得しますん。
image.png
リンク先のサイトの流れに沿ってアカウント取得。

DockerにCentOS8入れてバージョン確認までやってみよう

Docker Hub からCentOS8のイメージを取ってきます。
PowerShellで下記コマンド。

docker pull centos:centos8

docker images コマンド打つと、取得済のイメージ一覧見れます。
CentOS8入ってますね。
image.png

下記コマンドでコンテナを作成して起動、bashシェルの接続まで一気に行います。
（今回は『centos8_desu』という名前のコンテナにしてみました）

docker run -it --name="centos8_desu" centos:centos8 /bin/bash

じゃあ CentOSのバージョン確認コマンド を打ってバージョン確認してみましょい！
うん、取れた取れた！
image.png
あたいの自宅サーバーと同じバージョンだったから丁度よかったざんす。

コマンド覚えたくないマン参上！

Dockerコマンドというものがあるらしい。
（『コンテナの起動 or 停止』『コンテナへのログイン』とかそういうのをやるコマンド）

('A`)…GUIでいいや…。
image.png
image.png
マウスポチポチで端末開くところまでは行けるん。
image.png
早く検証環境整えないといけないから、Dockerコマンドは必要があればその都度覚えることにしました。

参考サイトさん

https://qiita.com/gahoh/items/7b21377b5c9e3ffddf4a

蛇足

  1. 『切り戻しイメージ』『お試しイメージ』のようにイメージをミラーリング。
  2. 『お試イメージ』でつまづいたらそのイメージを削除して『切り戻しイメージ』を複製して再チャレンジ。

みたいなことができるのかなあ？

環境のスナップショット的なものがサクッと取れると便利ですね。
そういうことってできるのかなあ？

バージョン

Windows10 Pro バージョン1909 OSビルド18363.1198

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-11-22T20:11:10+09:00

docker-compose.ymlで名前付きvolumeを使う方法

結論

僕もまだあまり理解できてないのでものすごく乱暴な説明なのですが、
下記のようにdocker-compose.ymlファイルを記述すると名前付きvolumeが使えます。

docer-compose.yml
version: '3'

services:
    web:
      build: .

      ...
      volumes:
          - .:/myapp      
          - gem_data:/usr/local/bundle
          #ここと
      ...
volumes:
  gem_data:
  #ここが大事です。

- gem_data:/usr/local/bundle
これが名前付きパスです。

上記コードの下部にある、

volumes:
    gem_data:

これが無いと
ERROR: Named volume "gem_data:/usr/local/bundle" is used in service "gem_data:" but no declaration was found in the volumes section.
とエラーが出てしまい相対パスや絶対パスを使わないと指定できないみたいです。

相対パスなどを使うよりは、名前付きパスを使う方が基本的にはいいみたいです。

参考

Docker上のMySQLのデータをVolumeでホストのディレクトリにマウントすると権限周りで面倒なことになる
https://qiita.com/ysd_marrrr/items/e8a50c43cff87951385c

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-11-22T19:58:31+09:00

MySQL 5.7(Docker)環境構築メモ

Dockerを用いてMySQL5.7環境を構築し、MySQL Workbenchで接続するまでの手順をまとめる。
※Dockerなどはインストール済みであること。

  • フォルダ構成
  project/
        ├ docker/
        |       └ data       # マウント場所
        |       └ db/
        |          ├ my.cnf  # 設定ファイル     
        └ docker-compose.yml

1.docker-compose.ymlを作成する。

   version: '3'

   services:
     db:
       image: mysql:5.7
       container_name: mysql_container
       environment:
         MYSQL_ROOT_PASSWORD: rootpass
         MYSQL_DATABASE: sample_db
         MYSQL_USER: mysqluser
         MYSQL_PASSWORD: mysqlpass
       volumes:
       - ./docker/db/data:/var/lib/mysql
       - ./docker/db/my.cnf:/etc/mysql/conf.d/my.cnf
       restart: always
       ports:
       - 3306:3306

※環境設定は自環境に合わせて適宜設定する。

2.my.cnf(MySQL設定ファイル)を作成する。

   [mysqld]
   character-set-server=utf8mb4
   collation-server=utf8mb4_unicode_ci

   [client]
   default-character-set=utf8mb4

※要件に合わせて適宜設定する。上例は文字コードのみを設定している。

3.MySQLコンテナを起動する。

上記projectフォルダに移動し、以下のdocker-composeコマンドを実行する。

   docker-compose up -d

※docker psコマンドを実行し、mysql_containerのステータスがUPになっていることを確認する。

4. MySQL Workbenchからコンテナにアクセスする。
※MySQL Workbenchは公式よりインストールする。

  1. タブDatabase -> Manage Connections... を選択する。

    以下のManage Server Connections画面が表示される。mysql_manage_server_connections.png

  2. Newを押下し、docker-compose.ymlに記載した接続情報を入力する。

  3. Test Connectionでコンテナに接続できるかを確認する。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-11-22T19:01:47+09:00

Keycloak 概要

Keycloakの概要情報をまとめる。学習目的記事。

Keycloakとは？

  • オープンソースのアイデンティティ・アクセス管理用ソフト。

Keycloakの機能

※以下、公式サイトより抜粋。

  • SSO/SLO
  • 以下のプロトコルサポート
    • OpenID Connect
    • OAuth 2.0
    • SAML
  • 外部のOpenID Connect/SAMLに対応しIdPによる認証。
  • ソーシャル・ログイン
  • ユーザー・フェデレーション
  • ユーザー、ロール、ロール・マッピング、クライアント設定の管理コンソール。
  • ユーザーに自身のアカウントを一元管理することを許可するためのアカウント管理コンソール。
  • 二要素認証
  • ログイン・フロー など...

Keycloakの概念

keycloak_concept.png

  • ユーザー
    • システムにログイン可能なエンティティーを指す。Eメール、ユーザー名、住所、電話番号、生年月日など自分自身に関連する属性を保持する。また、"グループ"や"ロール"が割り当てられることもある。
  • クレデンシャル
    • Keycloakがユーザーの身元を確認するために使用するデータの一部を指す。例：パスワード、ワンタイムパスワード、デジタル証明書、指紋など。
  • ロール
    • ユーザーのタイプまたはグループの識別子を指す。 Admin、user、 manager、employee などが組織内に存在するロールとして定義されている。パーミッションを割り当てて、複数のユーザーに対する制御が可能。ユーザーには0以上のロールをマッピング可能。
  • グループ
    • ユーザーの管理単位を指す。属性を定義可能。ロールをマッピングできる。グループのメンバーになったユーザーは、そのグループが定義する属性とロールのマッピングを継承する。
  • レルム
    • ユーザー、クレデンシャル、ロール、および、グループのセットを管理する主体を指す。ユーザーは属しているレルムにログインする。レルムは互いに分離され、制御するユーザーのみを管理し、認証できる。
  • クライアント
    • Keycloakにユーザーの認証を要求できるエンティティーを指す。Keycloakを使用して自身を保護し、シングル・サインオン機能を提供するアプリケーションとサービスを指す。また、クライアントはKeycloakによって保護されるネットワーク上の他サービスをセキュアに呼び出すために、アイデンティティー情報やアクセストークンを要求する。

ローカルDocker環境構築

ローカルでのDocker環境構築例
1. 以下のDockerコマンドを実行する。

   docker run -d -p 8080:8080 -e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=adminpass --name keycloak_test jboss/keycloak

※初期ユーザー情報やポート、コンテナ名は自環境に合わせて適宜設定する。
2. ブラウザからhttp://localhost:8080/auth/admin/ (ログイン画面)にアクセスする。
※以下の画面が表示される。
keycloak_login.png
3. 初期ユーザ admin パスワード adminpass でログインする。
※以下の画面が表示される。
keycloak_console.png

参考情報

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-11-22T15:03:58+09:00

【Rails6】Railsの既存アプリをDockerizeする【Docker】

はじめに

Hello,Qiita! :sunny:
今回は既存のRailsアプリをDockerに乗せてみようと思います！
コンテナの中に環境を移すというシンプルなものですが、
webpackやyarnのインストールで少し引っ掛かったので、記事にしてみました！
docker-composeでRailsとMySQLの2つのコンテナをオーケストレーションしてみましょう:musical_score:
それではいきましょう！！:whale2:

前提条件

  • OS: MacOS
  • Ruby: 2.7.1
  • Rails: 6.0.3
  • データベース: MySQL
  • Docker: 19.03.13

Dockerfileの記述

以下のように記述します。

Dockerfile
FROM ruby:2.7.1

ENV BUNDLER_VERSION="2.1.4" \
    APT_KEY_DONT_WARN_ON_DANGEROUS_USAGE=DontWarn \
    TZ=Asia/Tokyo

RUN apt-get update && apt-get install -y \
    build-essential \
    libpq-dev \
    nodejs \
    mariadb-client \
    sudo \
    vim && \
    curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add - && \
    echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list && \
    apt-get update && apt-get install -y yarn

WORKDIR /app

COPY Gemfile Gemfile.lock /app/

COPY . /app

RUN bundle install -j4 && \
    yarn upgrade && \
    rails webpacker:install && \
    yarn install --check-files

COPY entrypoint.sh /usr/bin/
RUN chmod +x /usr/bin/entrypoint.sh
ENTRYPOINT ["entrypoint.sh"]
EXPOSE 3000

CMD ["rails", "server", "-b", "0.0.0.0"]

何をやっているのか

FROM

Docker Hub にある（今回はRubyのバージョン2.7.1の）公式イメージを取ってくる。

ENV

環境変数の定義をする。

APT_KEY_DONT_WARN_ON_DANGEROUS_USAGE=DontWarn
↑これを書くとWarningメッセージを非表示にできる

RUN

Dockerコンテナ上でコマンドを実行する。

apt-get このコマンドは、Debian系ディストリビューション（DebianやUbuntu）のパッケージ管理システムであるAPT（Advanced Package Tool）ライブラリを利用してパッケージを操作・管理する、という意味。今回はRubyのイメージを取ってきたが、Debianイメージの上にrubyがインストールされてある。DebianはLinuxカーネルを利用しているためLinuxコマンドが使える。

WORKDIR

ワークディレクトリの設定をする。
同じDockerfile内に複数回指定可能で、ENVで登録したパスを利用してもよい。

COPY

新しいファイルをフォルダコピーする(圧縮されているファイルは展開されない)。

ENTRYPOINT

記述されたコマンドの実行をする。

EXPOSE

特定のポートを解放する。

CMD

実行するコンテナのデフォルト値を設定する。
同じDockerfile内で使用できるのは一回のみで、ENTRYPOINTに対して引数を設定することも可能である。
Dockerfileには、少なくとも一回はENTRYPOINTかCMDを記載すべき。

docker-compose.ymlの記述

以下のように記述します。

docker-compose.yml
version: '3'

services:
  app:
    build: .
    command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails s -p 3000 -b '0.0.0.0'"
    volumes:
      - .:/myapp
      - ./vendor/bundle:/myapp/vendor/bundle:delegated
    ports:
      - "19802:3000" # "任意のポート:3000" とする
    depends_on:
      - db
    tty: true
    stdin_open: true

  db:
    image: mysql:5.7
    environment:
      MYSQL_ROOT_PASSWORD: "password"
    ports:
      - "19801:3306" # こちらも、"任意のポート:3306"とする
    volumes:
      - ./tmp/db:/var/lib/mysql

何をやっているのか

version

使用するdocker-composeのバージョンを定義する。

services

アプリケーションを動かすための各要素(service)を定義する。(今回はappとdb)

build

composeファイルを実行し、ビルドされるときのパスを指定する。

command

デフォルトコマンドをオーバーライドする。

volumes

マウントする設定ファイルのパスを指定する。

ports

Dockerイメージを立ち上げる際のポート番号を指定する。

depends_on

service同士の依存関係を指定する。

environment

環境変数を指定する。

tty: true

コンテナが起動し続けるよう設定する。

stdin_open: true

コンテナ内の標準入出力の許可を設定する。

entrypoint.shの記述

以下のように記述します。

entrypoint.sh
#!/bin/bash
set -e

# Railsのserver.pidファイルを取り除く
rm -f /app/tmp/pids/server.pid

# コンテナのメインプロセスを実行する (DockerfileでCMDと設定されているもの)。
exec "$@"

database.ymlの記述

以下のように記述します。

database.yml
default: &default
  adapter: mysql2
  pool: 5
  timeout: 5000 # 任意

development:
  <<: *default
  database: myapp_development
  username: root
  password: password
  host: db
  port: 3306

GemfileとGemfile.lockの確認

今回は既存アプリをDockerにのせるので、GemfileとGemfile.lockが存在していることを確認するだけで良いです。

docker-composeの起動

ターミナルで
docker-compose build
を実行します。

ターミナル
Successfully built ~
Successfully tagged ~

と出力されればビルド成功です。

次に、
docker-compose exec app bash
を実行し、appコンテナ内に入ります。その後、
bundle exec rails db:create
bundle exec rails db:migrate
bundle exec rails db:seed
を実行し、無事完了です！:sunglasses:

終わりに

最後までご覧いただきありがとうございました。
個人的には、コンテナの中に入って作業をするのがめちゃ楽しいです。
なぜかはわかりません。（インセプション的な気持ちになる）
また、不適切な表現などありましたらお知らせいただけると幸いです。

それではまた！:rocket:

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-11-22T12:50:40+09:00

Docker Machine のコマンドメモ

DockerMachineのコマンド

項目 バージョン
docker-machine v0.12.2
VirtualBox 6.1.4

DockerMachineの作成から停止まで

作成

作成するマシン名は「test-box」とする。

$ docker-machine create --driver virtualbox test-box

一覧確認

$ docker-machine ls
NAME          ACTIVE   DRIVER       STATE     URL                         SWARM                DOCKER      ERRORS 
test-box      -        virtualbox   Running   tcp://192.168.99.110:2376                        v19.03.12

アクティブにする

$ eval $(docker-machine env test-box)
$ docker-machine ls
NAME          ACTIVE   DRIVER       STATE     URL                         SWARM                DOCKER      ERRORS 
test-box      *        virtualbox   Running   tcp://192.168.99.110:2376                        v19.03.12

SSHで接続してexitでログアウト

$ docker-machine ssh test-box
   ( '>')
  /) TC (\   Core is distributed with ABSOLUTELY NO WARRANTY.
 (/-_--_-\)           www.tinycorelinux.net

docker@test-box:~$ exit
logout

IPアドレス確認

$ docker-machine ip test-box
192.168.99.110

アクティブを解除

$ docker-machine ls
NAME          ACTIVE   DRIVER       STATE     URL                         SWARM                DOCKER      ERRORS 
test-box      *        virtualbox   Running   tcp://192.168.99.110:2376                        v19.03.12 
$ eval $(docker-machine env -u)
$ docker-machine ls
NAME          ACTIVE   DRIVER       STATE     URL                         SWARM                DOCKER      ERRORS 
test-box      -        virtualbox   Running   tcp://192.168.99.110:2376                        v19.03.12

Dockerマシンを停止

$ docker-machine stop test-box
Stopping "test-box"...
Machine "test-box" was stopped.

DockerMachine上でコンテナを実行

DockerMachine上でdockerコマンドを実行

DockerMachineがアクティブな状態でdockerコマンドを実行すると、そのコマンドはアクティブなDockerMachineのホスト上で実行していることになる。
以下はアクティブなtest-boxというDockerMachineホスト上で、nginxコンテナを実行している。
実行後に、test-boxホストのIPアドレスのポート番号8000にブラウザからアクセスする(192.168.99.110:8000)と「Welcome to nginx!」の画面が表示される。

$ docker-machine ls
NAME          ACTIVE   DRIVER       STATE     URL                         SWARM                DOCKER      ERRORS 
test-box      *        virtualbox   Running   tcp://192.168.99.110:2376                        v19.03.12 
$ docker run -d -p 8000:80 nginx
Unable to find image 'nginx:latest' locally
latest: Pulling from library/nginx
852e50cd189d: Pull complete 
a29b129f4109: Pull complete 
b3ddf1fa5595: Pull complete 
c5df295936d3: Pull complete 
232bf38931fc: Pull complete 
Digest: sha256:c3a1592d2b6d275bef4087573355827b200b00ffc2d9849890a4f3aa2128c4ae
Status: Downloaded newer image for nginx:latest
054e2f9af619f68c12dfa964772dcb9902ebfeed9c5805122dd4a967b87b88f7

作成したコンテナの確認

$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                  NAMES
054e2f9af619        nginx               "/docker-entrypoint.…"   2 hours ago         Up 9 minutes        0.0.0.0:8000->80/tcp   boring_chatelet

DockerMachineホスト上のコンテナのシェルに入る

$ docker exec -it 054e2f9af619 bash                              
root@054e2f9af619:/#
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-11-22T12:09:25+09:00

C++の環境をいい感じに構築

初めに

本記事では、自分が考えたC++の勉強し易い環境を作成する事を目的として記載しています。
その為、他の人から見たらあれこれあると思いますが・・・お優しい目で見ていいただければなと思います。

更新履歴

  • 2020/11/22:libtorch＋google testにを合わせたビルド環境に修正。

目的

C++開発での単体テスト勉強やcmakeの勉強を行える環境を構築する事を目的とする。
また、makeコマンドでいい感じにビルドやプロジェクトの作成をできるようにする。

ディレクトリ構成

以下のようディレクトリ構成にしました。

cpp_train/
├─cpp/                # C++の開発環境ディレクトリ
│  ├─project/         # プロジェクトごとにディレクトリを切る
│  ├─ ...
│  ├─.editorconfig    # c,h,cpp,hppに対しての設定
│  └─makefile         # build,clean,projectのコマンドを記載 
├─doc/                # 開発時のドキュメントやメモのディレクトリ
├─Docker/             # Dockerイメージのディレクトリ(環境ごとにディレクトリを切る)
│  ├─ubuntu/        
│  │  └─Dockerfile    # 必ずDockerfileにする。(変なファイル名にして指定する事はなるべくやりたく無いから)
│  └─windows/         # 今回は省略（サイレントインストール難しかったから）
│     └─Dockerfile
├─scripts/            # 環境開発に対してのスクリプトのディレクトリ(今回は特に必要ないので省略)
│  ├─switch_linux.bat # docker cliでLinuxコンテナに切り替えるスクリプト
│  └─switch_win.bat   # docker cliでWindowsコンテナに切り替えるスクリプト
├─template/           # make projectコマンドのテンプレート
│  └─project/
│       ├─include/
│       ├─lib/
│       ├─src/
│       ├─test/
│       └─CMakeLits.txt
├─.gitignore          # ignoreファイル
├─docker-compose.yml  # マウントを簡略化する為
└─README.md

Dockerイメージ

FROM ubuntu:20.04

ENV BOOST_VERSION 1.70.0
ENV BOOST_FILE_VERSION 1_70_0
ENV GOOGLE_TEST_VERSION 1.10.0
ENV PYTORCH_VERSION 1.7.0
ENV DEBIAN_FRONTEND=noninteractive


# 開発に必要なパッケージをインストール(ダウンロード元のリポジトリを日本サーバーに変更)
RUN sed -i 's@archive.ubuntu.com@ftp.jaist.ac.jp/pub/Linux@g' /etc/apt/sources.list \
    && apt-get -o Acquire::Check-Valid-Until=false -o Acquire::Check-Date=false update \
    && apt-get install --no-install-recommends -y \
        tzdata \
        build-essential \
        zlib1g-dev \
        libffi-dev \
        libpthread-stubs0-dev \
        cmake \
        gdb \
        curl \
        openssh-server \
        ca-certificates \
        zip \
        unzip \
    && apt-get clean \
    && rm -r /var/lib/apt/lists/* \
    && mkdir /tmp/src
# BoostとGoogle testとlibtorchをダウンロードし解凍する。
WORKDIR /tmp/src
RUN curl -OL https://dl.bintray.com/boostorg/release/${BOOST_VERSION}/source/boost_${BOOST_FILE_VERSION}.tar.gz\
    && tar -zxvf boost_${BOOST_FILE_VERSION}.tar.gz \
    && curl -OL https://github.com/google/googletest/archive/release-${GOOGLE_TEST_VERSION}.tar.gz \
    && tar -zxvf release-${GOOGLE_TEST_VERSION}.tar.gz \
    && mkdir ./googletest-release-${GOOGLE_TEST_VERSION}/build \
    && curl -OL https://download.pytorch.org/libtorch/cpu/libtorch-shared-with-deps-${PYTORCH_VERSION}%2Bcpu.zip \
    && unzip libtorch-shared-with-deps-${PYTORCH_VERSION}%2Bcpu.zip
# boostのインストール
WORKDIR /tmp/src/boost_${BOOST_FILE_VERSION}
RUN ./bootstrap.sh --prefix=/usr/local/ --with-libraries=program_options \
    && ./b2 install
# Libtorchのインストール(CPU only)
WORKDIR /tmp/src/libtorch
RUN cp -v -r include/* /usr/local/include \
    && cp -v -r lib/* /usr/local/lib \
    && cp -v -r share/* /usr/local/share/
# Google testのインストール
WORKDIR /tmp/src/googletest-release-${GOOGLE_TEST_VERSION}/build
# libtorchとgoogletestの競合対応(gtestするときはlibtorchのリンクが必須になる)
RUN sed -i -e "11i add_compile_definitions(_GLIBCXX_USE_CXX11_ABI=0)" ../CMakeLists.txt  \
    && cmake ..\
    && make \
    && make install

# インストール作業で出た一時的なファイルを削除
WORKDIR /tmp
RUN rm -rf ./src/
# 最後に作業場を参照
WORKDIR /tmp/project

ハマった点

  • ubuntuイメージでとあるpackageをapt-getするとtime zoneを聞かれるのでENV DEBIAN_FRONTEND=noninteractiveを入れて対応しています。
  • Google Testがlibtorchを入れるとABI周りで変なエラーが出力される為 Google Test側のCMakeLists.txtにコンパイルオプションを追加しています。

docker-compose.yml

マウントを簡略化する為だけに使用しています。
いちいちdockerコマンドをスクリプト化するよりいいかなと思います。

開発プロジェクト配下とプロジェクトテンプレート配下をマウントしています。

書いてて思ったのですが、
build/dockerfileの所がDockerfile指定しちゃっているので、ダサいですね。

version: '3'
services:
  dev_linux:
    build:
      context: .
      dockerfile: ./Docker/ubuntu/Dockerfile
    tty: True
    volumes:
      - ./cpp:/tmp/project
      - ./template:/tmp/src/template

makefile

ここでは、C++開発を効率的に行う為のコマンドを記載します。
その為、cppディレクトリ直下に置いています。

開発時は常にcppディレクトリ上でコマンドを使用するイメージです。

buildはプロジェクト配下にあるCMakeLists.txtを元にビルドまで行います。
出力は<c++プロジェクト>/buildに格納されるようにしています。

cleanはbuildで作成されたbuildディレクトリを削除する為のコマンドです。

projectはC++開発のプロジェクトテンプレートを、指定した名前のプロジェクト名に置き換えて作成するコマンドです。プロジェクトテンプレートはdocker-compose.ymlでマウントした先にある為そこを指定しコピーを行っています。その後CMakeLists.txtにproject名を記入するコマンドを行っています。

変数名を統一したほうがよかったと思っていますが、
変数必須の書き方忘れてしまった。。

.ONESHELL:
.PHONY: clean build

clean:
    -rm -r ./$(dir)/build

build: 
    cmake -S ./$(dir) -B ./$(dir)/build
    cmake --build ./$(dir)/build

.PHONY: project
project:
    cp -r /tmp/src/template/project $(name)
    sed -i -e "2i project($(name))" $(name)/CMakeLists.txt

template/

C++のプロジェクトテンプレートを格納しているディレクトリです。
最初はシェルコマンドでテンプレートが作成されるようにしようと思ったのですが、
難しいし、編集するのに癖があると思ったので実際にテンプレートプロジェクトを作成コピーさせるようにしました。

CMakeLits.txtファイル1つでビルドとテストが行えるようにしました。

project/
│       ├─include/ # ビルド・テスト両方で必要なソースを展開
│       ├─lib/  # 使用予定ないけどあったほうがそれっぽいので作っています。
│       ├─src/  # ビルドのみに必要なソースを展開
│       ├─test/ # テストのみに必要なソースを展開
│       └─CMakeLits.txt

CMakeLists.txt

CMakeを全然勉強していなかったのでここでかなり苦労しましたｗ
CMakeは人によって書き方がかなり違ってたりしたので、参考資料を集め公式のドキュメントと照らし合わせながら勉強しました。

工夫点

ここではあえてプロジェクト名を入れていません。
make projectで挿入されます。

testのif文は別に無くてもいいけど
あったほうが個人的に読みやすかったので、つけています。
testのパスもできるしね！

反省点

target_compile_featuresで指定しているオプションを変数に
入れてtestとbuildで統一したかったですが、setを使うのは推奨されていないっぽいので
どうしたらいいのかわからず直書きしてしまいました。

cmake_minimum_required(VERSION 3.16)

# 必須
find_package(Torch REQUIRED)

# Set macros
add_definitions(
)

# project
file(
    GLOB_RECURSE
    SOURCES
    ${PROJECT_SOURCE_DIR}/src/*.cpp
    ${PROJECT_SOURCE_DIR}/include/*.cpp
)

# test
file(
    GLOB_RECURSE
    TEST_SOURCES
    ${PROJECT_SOURCE_DIR}/test/*.cpp
    ${PROJECT_SOURCE_DIR}/include/*.cpp
)

# libs
include_directories(
    ${PROJECT_BINARY_DIR}
    ${PROJECT_SOURCE_DIR}/include
)
link_directories(
    ${PROJECT_SOURCE_DIR}/libs
)

# tests
if(NOT out-test)

    find_package(GTest REQUIRED)

    add_executable(
        ${PROJECT_NAME}-Test 
        ${TEST_SOURCES}
    )

    enable_testing()

    target_include_directories(
        ${PROJECT_NAME}-Test PRIVATE
        ${INCLUDE_DIRECTORIES}
        ${GTEST_INCLUDE_DIRS}
    )
    target_link_libraries(
        ${PROJECT_NAME}-Test PRIVATE
        ${LINK_DIRECTORIES}
        ${TORCH_LIBRARIES} #GTestを行う為必須
        GTest::GTest
        GTest::Main
    )
    target_compile_features(
        ${PROJECT_NAME}-Test PRIVATE
        cxx_std_14
    )

    gtest_add_tests(TARGET ${PROJECT_NAME}-Test)

endif()


add_executable(
    ${PROJECT_NAME} 
    ${SOURCES}
)
target_link_libraries(
    ${PROJECT_NAME} 
    ${LINK_DIRECTORIES}
    ${TORCH_LIBRARIES}
)
target_compile_features(
    ${PROJECT_NAME} PRIVATE
    cxx_std_14
)

開発イメージ

  1. docker-compose up -dでイメージをビルドしコンテナを起動
  2. dcoekr-compose exec dev_linux /bin/bash で開発環境にログイン
  3. make project name=<プロジェクト名>でプロジェクトを作成
  4. make build dir=<3のプロジェクト名>でビルドを行う。
  5. ./<プロジェクト名>/build/<プロジェクト名>で実行ファイルを実行
  6. ./<プロジェクト名>/build/<プロジェクト名>-Testでテスト結果を出力

ド素人ながら頑張ったなと思います。

所感

今後はWindows周りのコンテナやCLIを勉強しWindows・Linux環境の両方に対応した環境を構築したいと思っています。がサイレントインストールが難しいです。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-11-22T01:31:03+09:00

Litmus 101 - Chaos Engineering Framework

KubeCon NA Virtual 2020におけるLitmus

KubeCon NA Virtual 2020にて、Litmus+Argoの話が大変興味深かったため、Chaos Engineering FrameworkであるLitmusについて整理することにした。

講演概要: https://kccncna20.sched.com/event/ekDC/constructing-chaos-workflows-with-argo-and-litmuschaos-umasankar-mukkara-mayadata-sumit-nagal-intuit?iframe=no&w=100%&sidebar=yes&bg=no

講演資料: https://static.sched.com/hosted_files/kccncna20/c7/KubeCon Slides - Litmus%2BArgo.pdf

What's Litmus

LitmusはCloud NativeなChaos Engineering Frameworkです。システムにおける未知のバグや脆弱性を発見し、システムのResilience(回復性)を向上させることに役立てられます。

アイコンのひよこが、なんともいえないかわいさです。

Untitled.png

What's Chaos Engineering

IT分野においては、大規模な分散システムが当たり前になってきており、これらの複雑なシステムに対してどのように信頼性を担保できるかが注目されています。

この課題の解決策としてChaos Engineeringが注目されてきています。

Chaos Engineeringとは、混沌とした状態にも耐えうる信頼性の高いシステムを構築するために、システム上でさまざまな実験を行う学問または手法のことを指す言葉です。

参考: https://principlesofchaos.org

Architecrute of Litmus

下記は公式に記載されているアーキテクチャ図です。

順を追ってみていきます。

まずは、上半分からみていきます。

Untitled 1.png

Chaos OperatorはLitmus関連のCRDを管理するOperatorです。

このOperatorが、ChaosEngineをウォッチし管理します。

ChaosEngineはアプリケーションに対して、Chaos Experimentsを紐づける役割を持っています。

これにより、どのChaos Experimentsをどのアプリケーションに対して実行するかを特定できます。

右上のChaos Hubについては以降で詳しくみていきます。

左側のApplicationsは、Chaos Experimentsの適用対象のアプリケーションです。ここでアプリケーションといっていますが、Kubernetesのノードなどもここに含まれるような広い概念に見えます。(後述しますが、Kubernetesノード向けのChaos Experimentsもあるため)

Untitled 2.png

下部分についてもみていきます。

実際のChaos Experimentsの適用は、Chaos Runnerによって制御されます。

Chaos Experiments用のJobリソースが作成され、アプリケーションへの適用結果をChaos Resultとして出力します。

Untitled 1.png

Chaos Hub

DockerHubがDocker Image置き場なように、ChaosHubはChaosの実験セット(Chaos Experiments)が置いてあります。

かわいいひよこがお出迎えしてくれます

https://hub.litmuschaos.io

Untitled 3.png

Chaos Experimentsとは

ざっくり言うと、「用途ごとのシステムテスト群」です。

2020/11/20現在39のChaos Experimentsが公開されていますが、下記はその一部です。

  • podの削除
  • メモリ枯渇
  • 通信遮断
  • etc

このように、Chaos(混沌とした)という語感がミスリーディングなくらい、整理されています。(アイコンもおしゃれです。

それぞれのChaos Experimentsは下記の3カテゴリに分かれています。

Untitled 4.png

各Chaos Experimentsのページ

先程のアイコンをクリックすると、各Experimentのページにて詳細が見れます。

例えば、Chaos Experimentsがどんなテストをしてくれるかが書かれています。

Pod-deleteのページの場合、「指定したアプリケーションに対して、ランダムなPod削除操作を行う」ようです。

Deploymentのレプリカに対して強制的(Forced),もしくはGraceful(洗練された)Pod停止を引き起こせることが記載されています。

Untitled 5.png

さらにスクロールすると、実際にChaos Experiment(と必要なリソース)をコピペで導入する方法が書かれています。

ChaosExperiment自体はChaosExperiment CRD, CRとして導入されます。

ここに記載されているコマンドを、忙しい人向け、Getting Startedの章にて実行していきます。

Untitled 6.png

忙しい人向け

以降で実施するコマンドはKataKodaにて同様のことを15分程度確認できます。

https://www.katacoda.com/litmusbot/scenarios/getting-started-with-litmus#

Getting Started

クラスタを作成します

ここはお好きな方法で。

❯ kind create cluster

基本的に下記のページ通りです。

一部、分岐する表現や、Noteがちょろっと書かれているので、何も考えなくても実行できる状態のコマンドにしたものを紹介します。

Getting Started with Litmus · Litmus Docs

Litmus自体のインストール。

❯ kubectl apply -f https://litmuschaos.github.io/litmus/litmus-operator-v1.10.0.yaml
namespace/litmus created
serviceaccount/litmus created
clusterrole.rbac.authorization.k8s.io/litmus created
clusterrolebinding.rbac.authorization.k8s.io/litmus created
deployment.apps/chaos-operator-ce created
customresourcedefinition.apiextensions.k8s.io/chaosengines.litmuschaos.io created
customresourcedefinition.apiextensions.k8s.io/chaosexperiments.litmuschaos.io created
customresourcedefinition.apiextensions.k8s.io/chaosresults.litmuschaos.io created

Chaos Operatorが動作していることを確認できます。

❯ kubectl get pods -n litmus
NAME                                READY   STATUS    RESTARTS   AGE
chaos-operator-ce-5f998db95-dkrst   1/1     Running   0          56s

作業簡略化のため、namespaceを移動します。

❯ kubens litmus
Context "kind-kind" modified.
Active namespace is "litmus".

CRDとAPIがそれぞれ3つできていることを確認します。

❯ kubectl get crds | grep chaos
chaosengines.litmuschaos.io       2020-11-20T08:33:02Z
chaosexperiments.litmuschaos.io   2020-11-20T08:33:02Z
chaosresults.litmuschaos.io       2020-11-20T08:33:02Z

❯ kubectl api-resources | grep chaos
chaosengines                                   litmuschaos.io                 true         ChaosEngine
chaosexperiments                               litmuschaos.io                 true         ChaosExperiment
chaosresults                                   litmuschaos.io                 true         ChaosResult

Install Chaos Experiments

Chaos Experimentsをデプロイします。

ここで指定しているものは、Chaos Hub内のgeneric/all-experimentsです。

https://hub.litmuschaos.io/generic/all-experiments

❯ k create namespace nginx
namespace/nginx created

❯ kubectl apply -f https://hub.litmuschaos.io/api/chaos/1.10.0?file=charts/generic/experiments.yaml -n nginx
chaosexperiment.litmuschaos.io/pod-memory-hog created
chaosexperiment.litmuschaos.io/container-kill created
chaosexperiment.litmuschaos.io/node-cpu-hog created
chaosexperiment.litmuschaos.io/k8-pod-delete created
chaosexperiment.litmuschaos.io/pod-network-duplication created
chaosexperiment.litmuschaos.io/node-taint created
chaosexperiment.litmuschaos.io/k8-service-kill created
chaosexperiment.litmuschaos.io/pod-network-loss created
chaosexperiment.litmuschaos.io/kubelet-service-kill created
chaosexperiment.litmuschaos.io/disk-fill created
chaosexperiment.litmuschaos.io/disk-loss created
chaosexperiment.litmuschaos.io/pod-autoscaler created
chaosexperiment.litmuschaos.io/node-io-stress created
chaosexperiment.litmuschaos.io/pod-io-stress created
chaosexperiment.litmuschaos.io/docker-service-kill created
chaosexperiment.litmuschaos.io/pod-network-latency created
chaosexperiment.litmuschaos.io/node-memory-hog created
chaosexperiment.litmuschaos.io/pod-delete created
chaosexperiment.litmuschaos.io/pod-cpu-hog created
chaosexperiment.litmuschaos.io/node-drain created
chaosexperiment.litmuschaos.io/pod-network-corruption created

21個のChaos Experimentsが導入された。

この個数は、Chaos Hubにてgenericと検索した際に出てくる個数-1になる(all-experimentsも表示されるため)。

❯ kubectl get chaosexperiments -n nginx
NAME                      AGE
container-kill            43s
disk-fill                 43s
disk-loss                 43s
docker-service-kill       43s
k8-pod-delete             43s
k8-service-kill           43s
kubelet-service-kill      43s
node-cpu-hog              43s
node-drain                43s
node-io-stress            43s
node-memory-hog           43s
node-taint                43s
pod-autoscaler            43s
pod-cpu-hog               43s
pod-delete                43s
pod-io-stress             43s
pod-memory-hog            44s
pod-network-corruption    43s
pod-network-duplication   43s
pod-network-latency       43s
pod-network-loss          43s

Setup Service Account

rbacを適用します。簡単のためファイルが作成されないようにしています。

❯ kubectl apply -f - << EOF
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: pod-delete-sa
  namespace: nginx
  labels:
    name: pod-delete-sa
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-delete-sa
  namespace: nginx
  labels:
    name: pod-delete-sa
rules:
- apiGroups: ["","litmuschaos.io","batch","apps"]
  resources: ["pods","deployments","pods/log","events","jobs","chaosengines","chaosexperiments","chaosresults"]
  verbs: ["create","list","get","patch","update","delete","deletecollection"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-delete-sa
  namespace: nginx
  labels:
    name: pod-delete-sa
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: pod-delete-sa
subjects:
- kind: ServiceAccount
  name: pod-delete-sa
  namespace: nginx
EOF

serviceaccount/pod-delete-sa created
role.rbac.authorization.k8s.io/pod-delete-sa created
rolebinding.rbac.authorization.k8s.io/pod-delete-sa created

Deploy Your Application

Chaos Experimentsを適用するアプリケーションとしてnginxを起動します。

実際には、信頼性を高めたいアプリケーションがここに指定されていくことになります。

❯ k create deploy nginx -n nginx --image nginx
deployment.apps/nginx created

Annotate your application

Chaos Experimentsの影響範囲を限定したり、セキュリティ観点の指標の1つとして、実行対象のアプリケーションにannotationをつけてあげる必要があります。

❯ kubectl annotate deploy/nginx litmuschaos.io/chaos="true" -n nginx
deployment.apps/nginx annotated

Prepare ChaosEngine

ChaosEngineはアプリケーションをChaos Experimentsに接続してくれます。

詳細は割愛しますが、さまざまな設定項目があることが伺えます。

これを実行した段階で、Chaos Experimentsが実行され始めることになります。

❯ kubectl apply -f - << EOF
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: nginx-chaos
  namespace: nginx
spec:
  appinfo:
    appns: 'nginx'
    applabel: 'app=nginx'
    appkind: 'deployment'
  # It can be true/false
  annotationCheck: 'true'
  # It can be active/stop
  engineState: 'active'
  #ex. values: ns1:name=percona,ns2:run=nginx
  auxiliaryAppInfo: ''
  chaosServiceAccount: pod-delete-sa
  monitoring: false
  # It can be delete/retain
  jobCleanUpPolicy: 'delete'
  experiments:
    - name: pod-delete
      spec:
        components:
          env:
            # set chaos duration (in sec) as desired
            - name: TOTAL_CHAOS_DURATION
              value: '30'

            # set chaos interval (in sec) as desired
            - name: CHAOS_INTERVAL
              value: '10'

            # pod failures without '--force' & default terminationGracePeriodSeconds
            - name: FORCE
              value: 'false'
EOF

chaosengine.litmuschaos.io/nginx-chaos created

様子を見てみます。

何やら、nginxの他にchaos-runnerやpod-deleteというようなPodができています。

しばらくすると、それらのPodは消えます。

❯ k get po -n nginx
NAME                      READY   STATUS    RESTARTS   AGE
nginx-chaos-runner        1/1     Running   0          39s
nginx-f89759699-xvfkx     1/1     Running   0          8s
pod-delete-gvnw25-68wpx   1/1     Running   0          28s

❯ k get po -n nginx   
NAME                    READY   STATUS    RESTARTS   AGE
nginx-f89759699-8h4bh   1/1     Running   0          45s

Chaos Result

Chaos Experimentsの実行結果は、Chaos Result CRに書き込まれます。

完了していればEventとしてPassというステータスを確認できます。

実際にはここで、システムが壊れてくれれば、より信頼性の高いシステムにするための対策を打てることになります。

❯ kubectl describe chaosresult nginx-chaos-pod-delete -n nginx | grep Spec -A20
Spec:
  Engine:      nginx-chaos
  Experiment:  pod-delete
Status:
  Experimentstatus:
    Fail Step:  N/A
    Phase:      Completed
    Verdict:    Pass
Events:
  Type    Reason   Age    From                     Message
  ----    ------   ----   ----                     -------
  Normal  Awaited  2m48s  pod-delete-gvnw25-68wpx  experiment: pod-delete, Result: Awaited
  Normal  Pass     118s   pod-delete-gvnw25-68wpx  experiment: pod-delete, Result: Pass

Clean up

❯ kind delete cluster

Chaos Monitoring

Getting Startedで見てきた結果を、視覚的に確認することで知見を得やすくすることが期待できます。

Chaos experimentsを実行した際のメトリクスをウォッチすることで、テスト時のクラスタの様子をよりグラフィカルに見ることができます。

https://docs.litmuschaos.io/docs/next/monitoring/#monitoring-chaos

Chaos Experiments実行時に、CPU使用率がどれくらい上昇したのかなど、アドホックにメトリクスを見ることができます。

下記の例だと、赤い帯部分がChaos Runner実行時を示していてわかりやすいですね。

Untitled 7.png

Litmusの今後

KubeCon NA Virtual 2020における言及

2021年に注目される技術5選のうち、1つにChaos Exngineeringが含まれています。

今後も他のツールが出てくる可能性がありますが、Litmusがラップする形になっていくかと思われます。

Roadmap

Roadmapに記載されている内容について、気になる部分だけ抜粋します。

明確な時期は記載されていませんが、Near Termに実装予定とのこと。

https://github.com/litmuschaos/litmus/blob/master/ROADMAP.md

Litmus用のUIを提供

https://github.com/litmuschaos/litmus/wiki/portal-design-spec#litmus-portal-design-specification

(ログイン画面しかわかりませんが)Litmus用のWebUIが提供され、そこで諸々の操作を行えるようになることが期待できます。

Untitled 8.png

OpenEBS、Kafka、Cassandra向けのChaosResultをGrafanaダッシュボードで表示

別途Chaos-Exporter(Prometheus Exporter)を用意することで、Chaos ResultをGrafanaでみられるようにするエンハンスメントです。

今もメトリクスを見ることをできますが、既成のダッシュボードとして提供されるようになります。

https://github.com/litmuschaos/litmus/issues/1280

機能ごとにSIGを作成して、開発を促進

今後の開発がさらに加速することを期待できます。

まとめ

Chaos Engineering FrameworkであるLitmusの概要について紹介した。

CNCFとしても、2021年に注目すべき技術としてChaos Engineeringがあげられていることから、今後さらに開発が進むことが予想される。

現時点でもChaos Hubには39個のChaos Experimentsがあるが、今後はApplication固有のものが増えていくことが期待できる。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-11-22T01:16:27+09:00

Docker Desktop for WindowsをLinux(WSL)で操作

概要

WindowsにインストールしたDocker DesktopをWindowsにインストールしたLinux ディストリビューション(Ubuntu)で利用するためのセットアップ手順をメモ
なんらかのLinux ディストリビューションのインストールが終わっているのであれば、Docker Desktop の設定で WSL の統合を有効化するだけ
1.

Linux ディストリビューション(Ubuntu)のインストール

基本以下を見ればOK
Windows 10 用 Windows Subsystem for Linux のインストール ガイド

手順4までは、すでにDocker Desktopのセットアップを行っていれば、その際に実施済みのはず

手順 5 - WSL 21 を既定のバージョンとして設定する

PowerShellでコマンド実行
wsl --set-default-version 2

手順 6 - 選択した Linux ディストリビューションをインストールする

今回はUbuntu 20.04 LTSをインストール

Ubuntuを起動

初回起動時はusernameとpasswordを聞かれるので、任意の名前とパスワードを入力すればそのまま登録される
新しい Linux ディストリビューションのユーザー アカウントとパスワードを作成する

パッケージの更新とアップグレード

とりあえず、お約束
sudo apt update && sudo apt upgrade

dockerコマンド打ったら通らない、、、

満を持してWindows上のLinuxからdockerコマンド実行したが、期待した動きではないような、、

$ docker --version

The command 'docker' could not be found in this WSL 2 distro.
We recommend to activate the WSL integration in Docker Desktop settings.

See https://docs.docker.com/docker-for-windows/wsl/ for details.

Docker Desktopの設定をしてねという事らしい

Docker Desktop の設定で WSL の統合を有効化

DockerのSettings > Resources > WSL INTEGRATION でインストールしたLinuxディストリビューションへの統合を有効化
image.png

Ubuntu再起動

統合を有効化したら、Ubuntuアプリを再起動して改めてdockerコマンド実行したらdockerコマンド実行OK

$ docker --version
Docker version 19.03.13, build 4484c46d9d

これで、晴れてWindows上のDockerをWindows上のLinuxから操作できる

  1. WSL1とWSL2の違いについて WSL 1 と WSL 2 の比較の機能比較によるとWSL2は完全なLinuxカーネルとシステムコールの完全な互換性があり、WSL1と比較してzipファイルの展開が最大20倍早いとのこと、WindowsとLinux間でファイルのやり取りをする必要がある場合WSL1を利用するとよい場合もある模様  ↩

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

日付別

タグ一覧