この記事は NTTドコモテクニカルジャーナル Vol.29 No.1 クラウドオーケストレータを活用した複数 Kubernetes 管理の筆者による解説記事です。この記事ではクラウドオーケストレーターを使いはじめるためのインストールとセットアップ方法を紹介します。 クラウドオーケストレーターとは クラウドオーケストレーターは、複数のクラウドを管理するためのワンストップポータルです。 CMS である Drupal をベースにオープンソースとして公開されているため、どなたでも利用することができます。 クラウドオーケストレーターを使うメリット クラウドオーケストレーターを使うと、AWS、Kubernetes、OpenStack、VMware、Terraform Cloud といったさまざまなクラウドを一元的に管理できます。 シングルサインオンや Azure AD（Active Directory）で既存のシステムに統合できます。 Kubernetes のリソースの使用状況を分析、最適化し、運用コストを削減します。 インストール クラウドオーケストレーターをインストールするには、いくつかの方法があります。 AWS Marketplace から EC2 インスタンスを起動 CloudFormation から AWS 上に起動 PHP Composer からローカルやオンプレの環境にインストール 以下、３つの方法をそれぞれ説明します。 AWS Marketplace から起動 いちばん簡単な方法です。AWS Marketplace の Cloud Orchestrator から起動してください。 AWS CloudFormation を使う方法 ビデオマニュアル CloudFormation でインストールする方法 をご覧ください。 EC2、ECR、S3、IAM の管理者権限のアカウントが必要です。 テンプレートを起動し、スタックが完了するまで数分待ちます。 クラウドオーケストレーターの自動セットアップスクリプトが実行されます（十数分かかります）。 進行状況をみるには、サーバーに SSH で接続しログを確認します。 スタック作成が完了したら、Drupal URL をクリックします。 以下の表から、利用環境に合った CloudFormation テンプレートを選択してください。 構成 Apache2 Memached MariaDB VPC CloudFormation テンプレート EC2＋ElastiCache＋RDS EC2 ElastiCache RDS 自動作成 cloud_orchestrator_full.yaml EC2＋ElastiCache＋RDS EC2 ElastiCache RDS 既存利用 cloud_orchestrator_full_manual_vpc.yam EC2 シングルインスタンス EC2 EC2 EC2 自動作成 cloud_orchestrator_single.yam EC2 シングルインスタンス EC2 EC2 EC2 既存利用 cloud_orchestrator_single_manual_vpc.yam EC2 シングルインスタンス Docker Docker Docker 自動作成 cloud_orchestrator_docker.yaml EC2 シングルインスタンス Docker Docker Docker 既存利用 cloud_orchestrator_docker_manual_vpc.yaml EC2 上の Docker＋RDS Docker Docker RDS 既存利用 cloud_orchestrator_docker_rds_manual_vpc.yaml PHP Composer によるインストール ビデオマニュアル Composer でインストールする方法 をご覧ください。 はじめる前に、LAMP スタックと PHP の composer をあらかじめインストール・設定しておきます。 ターミナルを起動し、/var/www/cloud_orchestrator ディレクトリを作成・移動します。 mkdir /var/www/cloud_orchestratr && cd /var/www/cloud_orchestrator composer でクラウドオーケストレーターをインストールします。 composer create-project docomoinnovatins/cloud_orchestrator composer の実行終了後、ウェブブラウザーを開いて、サイトに移動します。 インストール手順に従ってサイトを設定します。 セットアップ ここでは、クラウドオーケストレーターで特に Kubernetes を管理するための設定方法を説明します。 Kubernetes の設定 アドミンユーザーを作成するための、以下の内容のマニフェストを作成します。 vi admin-user.yaml apiVersion: v1 kind: ServiceAccount metadata: name: admin-user namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: admin-user roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: admin-user namespace: kube-system マニフェストからアドミンユーザーを作成します。 kubectl apply -f admin-user.yaml 以下のコマンドを実行し、画面上に表示されるトークンを取得します。 export POD=$(kubectl -n kube-system get secret | grep admin-user-token | cut -f1 -d' ') && kubectl describe secret ${POD} --namespace kube-system クラウドオーケストレーターの設定 クラウドオーケストレーターにログインします。 Tour または Cloud service providers メニューから、K8s Cloud Service Provider を追加します。 API Server のフィールドにマスターノードの API エンドポイント URL、上で作成したアドミンユーザーのトークンを入力し、Save ボタンで保存します。 以下の画面が表示されれば成功です。 Cloud service providers メニューからクラスタを選択すると、各種リソースが確認できます。 複数の Kubernetes クラスターの管理 上記の手順にしたがって各クラスターのマスターノードの API エンドポイント URL とアドミンユーザーのトークンを取得、K8s Cloud Service Provider をそれぞれ追加することで複数の K8s クラスターをできます。 次のステップ クラウドオーケストレーターをもっと深く知りたい方のために、関連サイトをリストアップしておきます。 クラウドオーケストレーターのホームページ クラウドオーケストレーターの YouTube チャンネル クラウドオーケストレーターの開発サイト クラウドオーケストレーターのソースコード

はじめに M1MAC上でDockerを実行するとQEMM上でコードを実行することで、イメージによってかってにamd64イメージと、aarch64イメージが選択されます。 M1上で、通常のMACOSのプログラムを実行している気分でいるとamd64イメージでも2，3割程度のオーバーヘッドで動く気がしますが、QEMM上でKernelごと動かしている都合上もっとオーバーヘッドが想像以上に大きかったので、取りあえず測ってみました。 UNIXベンチの結果 M1MAXでDockerのResource設定でCPU8　メモリ20Gのときの結果です。 裏側でも微妙にブラウザとかつかってたので、あまり厳密な結果じゃないですが、AMD64イメージをM1MACのDockerで実行するとても遅いと言うことで。。 DOCKER上でAARCH64イメージを実行しているとき System Benchmarks Index Values BASELINE RESULT INDEX Dhrystone 2 using register variables 116700.0 55439770.2 4750.6 Double-Precision Whetstone 55.0 5969.6 1085.4 Execl Throughput 43.0 6479.6 1506.9 File Copy 1024 bufsize 2000 maxblocks 3960.0 614480.0 1551.7 File Copy 256 bufsize 500 maxblocks 1655.0 157878.0 953.9 File Copy 4096 bufsize 8000 maxblocks 5800.0 1866978.0 3218.9 Pipe Throughput 12440.0 944731.2 759.4 Pipe-based Context Switching 4000.0 17741.4 44.4 Process Creation 126.0 2757.5 218.9 Shell Scripts (1 concurrent) 42.4 8041.5 1896.6 Shell Scripts (8 concurrent) 6.0 3634.8 6057.9 System Call Overhead 15000.0 641956.6 428.0 ======== System Benchmarks Index Score 1024.8 DOCKER上でARM64イメージを実行しているとき System Benchmarks Index Values BASELINE RESULT INDEX Dhrystone 2 using register variables 116700.0 3783450.9 324.2 Double-Precision Whetstone 55.0 337.5 61.4 Execl Throughput 43.0 81.0 18.8 File Copy 1024 bufsize 2000 maxblocks 3960.0 464183.0 1172.2 File Copy 256 bufsize 500 maxblocks 1655.0 120919.0 730.6 File Copy 4096 bufsize 8000 maxblocks 5800.0 1465216.0 2526.2 Pipe Throughput 12440.0 694340.4 558.2 Pipe-based Context Switching 4000.0 16642.8 41.6 Process Creation 126.0 543.9 43.2 Shell Scripts (1 concurrent) 42.4 329.2 77.6 Shell Scripts (8 concurrent) 6.0 139.3 232.1 System Call Overhead 15000.0 434722.2 289.8 ======== System Benchmarks Index Score 200.6 一応、参考までにExperimental Features にある Use the new virtualization frameworkにチェックをいれたときのAMD64の結果も載せときます。 System Benchmarks Index Values BASELINE RESULT INDEX Dhrystone 2 using register variables 116700.0 3788495.6 324.6 Double-Precision Whetstone 55.0 339.6 61.7 Execl Throughput 43.0 82.7 19.2 File Copy 1024 bufsize 2000 maxblocks 3960.0 487335.0 1230.6 File Copy 256 bufsize 500 maxblocks 1655.0 125785.0 760.0 File Copy 4096 bufsize 8000 maxblocks 5800.0 1659651.0 2861.5 Pipe Throughput 12440.0 736066.3 591.7 Pipe-based Context Switching 4000.0 24887.4 62.2 Process Creation 126.0 739.6 58.7 Shell Scripts (1 concurrent) 42.4 384.1 90.6 Shell Scripts (8 concurrent) 6.0 171.0 285.0 System Call Overhead 15000.0 457701.0 305.1 ======== System Benchmarks Index Score 225.8 M1 上でのDocker 個人的には一般的な用途というよりは、Dockerをマシンラーニングの環境構築を楽にするためにつかっているので、いろいろM1上のDockerだと制限が多いです。 AMD64の実行は、動くだけでハッピーなのですがそれ以上にUSBパススルーができないからはじまり、カメラとかAudioデバイスをDockerコンテナ上で扱うことが出来ないのがパフォーマンス以上に痛いです。 同様に、GPUにしてもニューラルエンジンにしてもせっかくあってもDoocker上からは使う方法がみつかりません。 速くDocker上からUSBへのダイレクトアクセスと、GPU,ニューラルエンジンが使えるようになって欲しい

はじめに Ubuntu 20.04 で docker scan をやってみました。 doceker scan は CLI 上からイメージの脆弱性を検査する docker コマンドの機能です。 スキャナは snyk の脆弱性スキャン SaaS を利用しています。 docker CLI はイメージの情報を syk のサーバに送信して、スキャン結果を出力することをやってくれます。 環境 動作環境は以下のとおりです。 Ubuntu $ cat /etc/os-release NAME="Ubuntu" VERSION="20.04.2 LTS (Focal Fossa)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 20.04.2 LTS" VERSION_ID="20.04" HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" VERSION_CODENAME=focal UBUNTU_CODENAME=focal docker $ docker --version Docker version 20.10.11, build dea9396 $ docker scan --version Version: v0.9.0 Git commit: b05830d Provider: Snyk (1.563.0 (standalone)) スキャンしようとするが・・・ Docker のマニュアルに沿ってとりあえずスキャンしようとしたもののいくつかエラーが出ました・・・。 順番に処置していきましょう。 ログインを要求された スキャンの前に DockerHub へのログインを要求されました。 エラー $ docker scan hello-world Docker Scan relies upon access to Snyk, a third party provider, do you consent to proceed using Snyk? (y/N) y failed to get DockerScanID: You need to be logged in to Docker Hub to use scan feature. please login to Docker Hub using the Docker Login command docker scan は DockerHub の無料アカウントを持っていると毎月 10 回まで無料で実行できる機能です。 有償アカウントだとさらにスキャンできる回数が増えます。 とりあえず docker login しましょう。 回避策 $ docker login Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one. Username: ****** Password: WARNING! Your password will be stored unencrypted in /home/******/.docker/config.json. Configure a credential helper to remove this warning. See https://docs.docker.com/engine/reference/commandline/login/#credentials-store Login Succeeded 400 bad request docker login 後にスキャンしようとするものの、ふたたびエラーが出ました。 $ docker scan hello-world failed to get DockerScanID: bad status code "400 Bad Request" docker scan は、 snyk の脆弱性スキャン SaaS を使用するツールで、snyk のアカウントを作らないとスキャンできません。 DockerScanID というのは snyk のアカウントのことのようです。メンドクサイですね。 --login オプションで snyk にスキャンします。 $ docker scan --login To authenticate your account, open the below URL in your browser. After your authentication is complete, return to this prompt to start using Snyk. https://snyk.io/login?****** 表示された URL をブラウザで表示します。 Docker ID と紐づけたいので、Docker ID ボタンをクリックします。 Authenticate ボタンをクリックします。 認証されました。 しかし、コマンドラインを見ると認証失敗のエラーが出てます。 Authentication failed. Please check the API token on https://snyk.io よくわかりませんね・・・。 以下のサイトを参考に ブラウザで snyk にログインして、 アカウント設定画面から click to show をクリックして、API キーを表示します。 --token オプションの引数に API キーを指定してログインを実行します。 $ docker scan --login --token **************************** Your account has been authenticated. Snyk is now ready to be used. これでようやくスキャンの準備が整いました。 スキャン実行 脆弱性を含まないイメージをスキャンする docker 公式のイメージ hello-world をスキャンしてみます。 $ docker scan hello-world Testing hello-world... Organization: kannkyo Package manager: linux Project name: docker-image|hello-world Docker image: hello-world Platform: linux/amd64 Licenses: enabled ✓ Tested hello-world for known issues, no vulnerable paths found. Note that we do not currently have vulnerability data for your image. 脆弱性が検出されませんでした。 安全なイメージですね。 脆弱性を含むイメージをスキャンする docker 公式のイメージ httpd:2.4.51 をスキャンしてみます。 脅威度の高い脆弱性だけを対象とするため、--severity=high オプションをつけました。 $ docker scan --severity=high httpd:2.4.51 Testing httpd:2.4.51... ✗ High severity vulnerability found in curl/libcurl4 Description: Cleartext Transmission of Sensitive Information Info: https://snyk.io/vuln/SNYK-DEBIAN11-CURL-1585138 Introduced through: curl/libcurl4@7.74.0-1.3+b1 From: curl/libcurl4@7.74.0-1.3+b1 Image layer: Introduced by your base image (httpd:2.4.51-bullseye) ✗ Critical severity vulnerability found in glibc/libc-bin Description: Use After Free Info: https://snyk.io/vuln/SNYK-DEBIAN11-GLIBC-1296898 Introduced through: glibc/libc-bin@2.31-13+deb11u2, meta-common-packages@meta From: glibc/libc-bin@2.31-13+deb11u2 From: meta-common-packages@meta > glibc/libc6@2.31-13+deb11u2 Image layer: Introduced by your base image (httpd:2.4.51-bullseye) ✗ Critical severity vulnerability found in curl/libcurl4 Description: Double Free Info: https://snyk.io/vuln/SNYK-DEBIAN11-CURL-1585150 Introduced through: curl/libcurl4@7.74.0-1.3+b1 From: curl/libcurl4@7.74.0-1.3+b1 Image layer: Introduced by your base image (httpd:2.4.51-bullseye) Organization: kannkyo Package manager: deb Project name: docker-image|httpd Docker image: httpd:2.4.51 Platform: linux/amd64 Base image: httpd:2.4.51-bullseye Licenses: enabled Tested 115 dependencies for known issues, found 3 issues. According to our scan, you are currently using the most secure version of the selected base image 実行ログの最後の 2 行がスキャン結果のサマリーです。 Tested 115 dependencies for known issues, found 3 issues. 115の依存関係について既知の問題をテストし、3つの問題を発見しました。 According to our scan, you are currently using the most secure version of the selected base image スキャンの結果、お客様は現在、選択されたベースイメージの最も安全なバージョンを使用しています。 curl, gtlibc についての 3 つの脆弱性が発見されました。 また、脆弱性が含まれるものの、httpd イメージの中では最も安全なバージョンを使用していることがわかりました。 3 つの脆弱性の詳細を見てみます。 パッケージ 脆弱性 CVE 脅威度 curl/libcurl4 Cleartext Transmission of Sensitive Information in curl CVE-2021-22946 7.5 glibc/libc-bin Use After Free in glibc CVE-2021-33574 9.8 curl/libcurl4 Double Free in curl CVE-2021-22945 9.1 curl と glibc についての脆弱性が出てます。 脅威度は最大で 10 です。9.8 はかなり高いです。 使わないパッケージであれば、httpd イメージから削除した別のイメージを作ったほうが良いです。 Dockerfileとベースイメージに脆弱性を含むイメージをスキャンする 次に、ベースイメージに先程の httpd:2.4.51 を使用し、さらに Dockerfile に脆弱性を埋め込んだイメージをスキャンします。 スキャン対象のイメージの Dockerfile は以下です。 $ docker scan ghcr.io/kannkyo/buggy-docker:v0.0.1 Testing ghcr.io/kannkyo/buggy-docker:v0.0.1... ✗ Low severity vulnerability found in tar Description: CVE-2005-2541 Info: https://snyk.io/vuln/SNYK-DEBIAN11-TAR-523480 Introduced through: meta-common-packages@meta From: meta-common-packages@meta > tar@1.34+dfsg-1 ✗ Low severity vulnerability found in systemd/libsystemd0 Description: Authentication Bypass Info: https://snyk.io/vuln/SNYK-DEBIAN11-SYSTEMD-1291054 Introduced through: systemd/libsystemd0@247.3-6, apt@2.2.4, util-linux/bsdutils@1:2.36.1-8, util-linux/mount@2.36.1-8, systemd/libudev1@247.3-6 From: systemd/libsystemd0@247.3-6 From: apt@2.2.4 > systemd/libsystemd0@247.3-6 From: util-linux/bsdutils@1:2.36.1-8 > systemd/libsystemd0@247.3-6 and 5 more... ... ✗ Medium severity vulnerability found in curl/libcurl4 Description: Insufficient Verification of Data Authenticity Info: https://snyk.io/vuln/SNYK-DEBIAN11-CURL-1585148 Introduced through: curl/libcurl4@7.74.0-1.3+b1 From: curl/libcurl4@7.74.0-1.3+b1 ✗ High severity vulnerability found in curl/libcurl4 Description: Cleartext Transmission of Sensitive Information Info: https://snyk.io/vuln/SNYK-DEBIAN11-CURL-1585138 Introduced through: curl/libcurl4@7.74.0-1.3+b1 From: curl/libcurl4@7.74.0-1.3+b1 ✗ Critical severity vulnerability found in glibc/libc-bin Description: Use After Free Info: https://snyk.io/vuln/SNYK-DEBIAN11-GLIBC-1296898 Introduced through: glibc/libc-bin@2.31-13+deb11u2, meta-common-packages@meta From: glibc/libc-bin@2.31-13+deb11u2 From: meta-common-packages@meta > glibc/libc6@2.31-13+deb11u2 ✗ Critical severity vulnerability found in curl/libcurl4 Description: Double Free Info: https://snyk.io/vuln/SNYK-DEBIAN11-CURL-1585150 Introduced through: curl/libcurl4@7.74.0-1.3+b1 From: curl/libcurl4@7.74.0-1.3+b1 Organization: kannkyo Package manager: deb Project name: docker-image|ghcr.io/kannkyo/buggy-docker Docker image: ghcr.io/kannkyo/buggy-docker:v0.0.1 Platform: linux/amd64 Base image: httpd:2.4.51-bullseye Licenses: enabled Tested 115 dependencies for known issues, found 52 issues. According to our scan, you are currently using the most secure version of the selected base image 詳細なログはこちら 52 件の脆弱性が検出されました。 多すぎてよくわからないので、docker scan コマンドのオプションを使ってもう少し調べてみます。 ベースイメージの脆弱性を対象外にする --exclude-base オプションを使用して、ベースイメージ httpd の脆弱性を対象外にします。 これで、自分が作った Dockerfile による脆弱性だけを抽出します。 $ docker scan --file Dockerfile --exclude-base ghcr.io/kannkyo/buggy-docker:v0.0.1 Testing ghcr.io/kannkyo/buggy-docker:v0.0.1... Organization: kannkyo Package manager: deb Target file: /app/Dockerfile Project name: docker-image|ghcr.io/kannkyo/buggy-docker Docker image: ghcr.io/kannkyo/buggy-docker:v0.0.1 Platform: linux/amd64 Base image: httpd:2.4.51 Licenses: enabled Tested 115 dependencies for known issues, found 0 issues. According to our scan, you are currently using the most secure version of the selected base image 脆弱性が検出されませんでした。 どうやら Dockerfile についての脆弱性は検出できないようです。 脅威度の高い脆弱性の情報を詳細に出力する --serverity オプションと --dependency-tree オプションを使って次の脅威度の脆弱性を含むパッケージの情報を詳細に出力します。 --dependency-tree オプションは、脆弱性の依存関係を可視化するオプションです。 $ docker scan --dependency-tree --severity=high ghcr.io/kannkyo/buggy-docker:v0.0.1 docker-image|ghcr.io/kannkyo/buggy-docker @ v0.0.1 ... ├─ curl/libcurl4 @ 7.74.0-1.3+b1 │ ├─ brotli/libbrotli1 @ 1.0.9-2+b2 │ ├─ krb5/libgssapi-krb5-2 @ 1.18.3-6+deb11u1 │ │ ├─ e2fsprogs/libcom-err2 @ 1.46.2-2 │ │ ├─ krb5/libk5crypto3 @ 1.18.3-6+deb11u1 │ │ └─ krb5/libkrb5-3 @ 1.18.3-6+deb11u1 │ │ ├─ e2fsprogs/libcom-err2 @ 1.46.2-2 │ │ ├─ keyutils/libkeyutils1 @ 1.6.1-2 │ │ ├─ krb5/libk5crypto3 @ 1.18.3-6+deb11u1 │ │ └─ openssl/libssl1.1 @ 1.1.1k-1+deb11u1 │ ├─ libidn2/libidn2-0 @ 2.3.0-5 │ ├─ libpsl/libpsl5 @ 0.21.0-1.2 │ │ ├─ libidn2/libidn2-0 @ 2.3.0-5 │ │ └─ libunistring/libunistring2 @ 0.9.10-4 │ ├─ libssh2/libssh2-1 @ 1.9.0-2 │ │ └─ libgcrypt20 @ 1.8.7-6 │ │ └─ libgpg-error/libgpg-error0 @ 1.38-2 │ ├─ nghttp2/libnghttp2-14 @ 1.43.0-1 │ ├─ openldap/libldap-2.4-2 @ 2.4.57+dfsg-3 │ ├─ openssl/libssl1.1 @ 1.1.1k-1+deb11u1 │ └─ rtmpdump/librtmp1 @ 2.4+20151223.gitfa8646d.1-2+b2 │ ├─ gmp/libgmp10 @ 2:6.2.1+dfsg-1 │ ├─ gnutls28/libgnutls30 @ 3.7.1-5 │ ├─ nettle/libhogweed6 @ 3.7.3-1 │ └─ nettle/libnettle8 @ 3.7.3-1 ... ├─ glibc/libc-bin @ 2.31-13+deb11u2 ... └─ xxhash/libxxhash0 @ 0.8.0-2 Testing ghcr.io/kannkyo/buggy-docker:v0.0.1... ✗ High severity vulnerability found in curl/libcurl4 Description: Cleartext Transmission of Sensitive Information Info: https://snyk.io/vuln/SNYK-DEBIAN11-CURL-1585138 Introduced through: curl/libcurl4@7.74.0-1.3+b1 From: curl/libcurl4@7.74.0-1.3+b1 ✗ Critical severity vulnerability found in glibc/libc-bin Description: Use After Free Info: https://snyk.io/vuln/SNYK-DEBIAN11-GLIBC-1296898 Introduced through: glibc/libc-bin@2.31-13+deb11u2, meta-common-packages@meta From: glibc/libc-bin@2.31-13+deb11u2 From: meta-common-packages@meta > glibc/libc6@2.31-13+deb11u2 ✗ Critical severity vulnerability found in curl/libcurl4 Description: Double Free Info: https://snyk.io/vuln/SNYK-DEBIAN11-CURL-1585150 Introduced through: curl/libcurl4@7.74.0-1.3+b1 From: curl/libcurl4@7.74.0-1.3+b1 Organization: kannkyo Package manager: deb Project name: docker-image|ghcr.io/kannkyo/buggy-docker Docker image: ghcr.io/kannkyo/buggy-docker:v0.0.1 Platform: linux/amd64 Base image: httpd:2.4.51-bullseye Licenses: enabled Tested 115 dependencies for known issues, found 3 issues. According to our scan, you are currently using the most secure version of the selected base image すべての脆弱性の依存関係が出力されました。 --severity オプションを併用しても、依存関係をフィルタできないみたいですね。 脆弱性を含むイメージをスキャンする Dockerfile の中で cron パッケージをインストールしたパッケージを作成します。 cron をインストールする際に、exim4-config がインストールされます。 $ apt-get install cron The following NEW packages will be installed: ca-certificates cron exim4-base exim4-config exim4-daemon-light gsasl-common guile-2.2-libs libevent-2.1-7 libfribidi0 libgc1 libgnutls-dane0 libgpm2 libgsasl7 libidn11 libltdl7 libmailutils7 libmariadb3 libmpdec3 libncurses6 libncursesw6 libntlm0 libpython3.9 libpython3.9-minimal libpython3.9-stdlib libreadline8 libsqlite3-0 libunbound8 mailutils mailutils-common mariadb-common media-types mysql-common netbase openssl psmisc readline-common sensible-utils 0 upgraded, 37 newly installed, 0 to remove and 0 not upgraded. exim4-config は、インジェクション攻撃に対する脆弱性 CVE-2021-38371 を含んでいます。 新しいイメージをスキャンします。 $ docker scan --severity=high ghcr.io/kannkyo/buggy-docker:v0.0.2 Testing ghcr.io/kannkyo/buggy-docker:v0.0.2... ✗ High severity vulnerability found in exim4/exim4-config Description: Arbitrary Code Injection Info: https://snyk.io/vuln/SNYK-DEBIAN11-EXIM4-1538494 Introduced through: exim4/exim4-config@4.94.2-7, exim4/exim4-base@4.94.2-7, exim4/exim4-daemon-light@4.94.2-7 From: exim4/exim4-config@4.94.2-7 From: exim4/exim4-base@4.94.2-7 > exim4/exim4-config@4.94.2-7 From: exim4/exim4-base@4.94.2-7 and 2 more... Image layer: Introduced by your base image (httpd:2.4.51-bullseye) ✗ High severity vulnerability found in curl/libcurl4 Description: Cleartext Transmission of Sensitive Information Info: https://snyk.io/vuln/SNYK-DEBIAN11-CURL-1585138 Introduced through: curl/libcurl4@7.74.0-1.3+b1 From: curl/libcurl4@7.74.0-1.3+b1 Image layer: Introduced by your base image (httpd:2.4.51-bullseye) ✗ Critical severity vulnerability found in python3.9/libpython3.9-minimal Description: Improper Input Validation Info: https://snyk.io/vuln/SNYK-DEBIAN11-PYTHON39-1290158 Introduced through: python3.9/libpython3.9-minimal@3.9.2-1, mailutils/libmailutils7@1:3.10-3+b1, python3.9/libpython3.9-stdlib@3.9.2-1, python3.9/libpython3.9@3.9.2-1 From: python3.9/libpython3.9-minimal@3.9.2-1 From: mailutils/libmailutils7@1:3.10-3+b1 > python3.9/libpython3.9@3.9.2-1 > python3.9/libpython3.9-stdlib@3.9.2-1 > python3.9/libpython3.9-minimal@3.9.2-1 From: python3.9/libpython3.9-stdlib@3.9.2-1 and 3 more... Image layer: Introduced by your base image (httpd:2.4.51-bullseye) ✗ Critical severity vulnerability found in glibc/libc-bin Description: Use After Free Info: https://snyk.io/vuln/SNYK-DEBIAN11-GLIBC-1296898 Introduced through: glibc/libc-bin@2.31-13+deb11u2, meta-common-packages@meta From: glibc/libc-bin@2.31-13+deb11u2 From: meta-common-packages@meta > glibc/libc6@2.31-13+deb11u2 Image layer: Introduced by your base image (httpd:2.4.51-bullseye) ✗ Critical severity vulnerability found in curl/libcurl4 Description: Double Free Info: https://snyk.io/vuln/SNYK-DEBIAN11-CURL-1585150 Introduced through: curl/libcurl4@7.74.0-1.3+b1 From: curl/libcurl4@7.74.0-1.3+b1 Image layer: Introduced by your base image (httpd:2.4.51-bullseye) Organization: kannkyo Package manager: deb Project name: docker-image|ghcr.io/kannkyo/buggy-docker Docker image: ghcr.io/kannkyo/buggy-docker:v0.0.2 Platform: linux/amd64 Base image: httpd:2.4.51-bullseye Licenses: enabled Tested 152 dependencies for known issues, found 5 issues. According to our scan, you are currently using the most secure version of the selected base image 新しい脆弱性 2 つを含む 5 つの脆弱性が検出されました。 exim4-config だけでなく libpython3.9-minimal の脆弱性も検出しました。 新しい脆弱性のスキャン結果をよく見ると、 Image layer: Introduced by your base image (httpd:2.4.51-bullseye) 「ベースイメージで作り込まれた」と書いてあります。誤検知ですね。 脆弱性そのものは検出できても、脆弱性がどのレイヤーに含まれるかという点の精度は甘いようです。 評価 docker scan の 良い点 Snyk と Docker のアカウントが連携していて、Docker CLI から snyk の脆弱性をスキャンできるのでツール導入の敷居がグッと低いですね。 パッケージの依存関係をツリー構造で可視化してくれる機能は、すごく便利です。 他の脆弱性スキャナーの GitHub Code Scanning には、依存関係を可視化する機能はありません。 パッケージ A, B, C をインストールした後に、パッケージ A が依存するパッケージ D で脆弱性エラーが出ときとかに解析がすごく楽になります。 docker scan の 悪い点 スキャンする前のログイン作業は結構面倒でしたね。もう少しわかりやすくならないのでしょうか。 パッケージの脆弱性は発見できましたが、Dockerfile の脆弱性は発見できませんでした。 脆弱性が含まれるレイヤーの識別の精度が甘いという欠点がありました。 まとめ docker scan は総じて導入の敷居が低く、簡単にイメージのスキャンができる使いやすいツールでした。 Dockerfile の脆弱性をチェックできる sysdiglabs/benchmark-dockerfile なんかと組み合わせて使えばセキュアなコンテナの開発に役立つかと、思います。 参考サイト

はじめに 一昨年、昨年と参加したPleasanterのアドベントカレンダーに今年もエントリーさせていただきました！ 今年はなかなか新機能等が追えていないのですがサーバスクリプトの機能が一気に増えていったりスマホ対応版がリリースされたりと、やはりそのスピード感には圧倒されます。 まだ触ることができていませんが、個人的にプリザンターSDKについてもとても気になっているのでいずれ時間が空いた時にでも触ってみたいですね！ Docker上でも簡単に動かしてみたい！ プリザンターは60日間無料で触ることのできるPleasanter for Demoというデモ環境がありますが、「ローカルでデモ環境を動かしたい」「メアド登録がちょっと抵抗ある」などの場合は自前で環境を構築する必要があります。 自前で環境を構築していく際は以下の手順書等を見ながら進めていくのですが、中にはお試しで触るのにローカルPCにアプリやデータベース等を入れたくない！（もしくは構築に時間をかけたくない！ハマると時間かかるし！）という方もいらっしゃるかと思われます。 ので、今回はそんなサクッと触ってみたいという方向けに「Pleasanter1.2 + PostgreSQL」の環境を速攻で作れるようなdocker-composeファイルを作ってみました！ システム構成図 今回Docker上に作った環境は以下のような構成になっています。 ※今回、Pleasanter1.2のアプリについては以下のZipファイルから取得しているのでバージョンはPleasanter_1.2.20.0固定です。 GithubのREADMEには記載していますが、WebフォルダのDockerfile内にダウンロード対象のURLを書いているのでそちらを変更すれば任意のバージョンをダウンロード可能です。 利用手順 今回のアプリを利用するにあたり、以下がローカルPCにインストールされている必要がありますのでご注意ください。 Git Docker docker-compose それでは利用手順を以下に記載します。 ①以下のコマンドでソースコードをクローンします。 git clone https://github.com/Oooooomin2/docker-pleasanter-postgresql.git 以下のようになればOKです！ ②docker-compose.ymlファイルと同じフォルダ内にて以下のコマンドを打ち、環境を構築します。 docker-compose up -d 色々出てきますが、以下のようになればOKです！ ③http://localhost:5000へアクセスし、Pleasanterのログイン画面が開くことを確認します。 初回ログイン情報は以下です。 ログインID: Administrator パスワード: pleasanter 制約 一応デモ版ということで...色々と制約はあります。 ①あくまでデモ用のため、データベースの永続化を行っておりません。永続化が必要な場合は任意の箇所にマウントしてデータを保管する必要があります。 ②PostgreSQLのデータベースのユーザ名、パスワードは今回は固定でセットしていますので変更ができません。あくまでデモ用としてご利用いただければと思います。 ③ナビゲーションメニューの検索欄が利用できません（検索するとアプリケーションエラーが発生します）。何かしら対策があったような気がしますが・・・ちょっと忘れちゃいました(;^_^A 今回作成したソース 今回作成したソースは以下にて公開しております。 PostgreSQLのイメージは以下のDocker Hubに格納しています。 おわりに 最近プリザンターを触ることができていなかったので、久々にログイン画面が表示されたときは懐かしい！！と感動しちゃいました（笑） 今後の活躍も楽しみにしていたいと思います！

はじめに Dockerって何？って人が起動成功するまでの流れを記載します。 参考にした記事は以下です。 https://sukkiri.jp/technologies/virtualizers/docker/docker-win_install.html 重要 この記事で紹介するDocker for Windowsを利用するには、PCが以下の要件を満たす必要があります。 64bit版のWindows 10（バージョン1511、ビルド10586以降）、ProもしくはEnterprise／Educationエディション Hyper-Vが利用できること コンテナ実行用の仮想マシンには、メモリ2GB、ディスク60GB（容量可変タイプの仮想ディスクで、初期サイズは4GB程度）のリソースが必要 Hyper-Vが有効になっているか確認する方法/Hyper-Vを有効にする方法は、以下に記載しています。 Dockerのサイトにアクセス 以下にアクセス Docker: https://www.docker.com/ 右上の「Get started」をクリック 「Docker Desktop」の「Download for Windows」から、ダウンロード。 Dockerのインストール ダウンロードしたインストーラーを実行。 ２点の確認項目が出てきます。 これは、和訳すると次の通りです。 - WSL2のインストールが必須であること - デスクトップにショートカットを作成するか Hyper-VでVirtualboxが起動しなくなった人向け 余談ですが、PC再起動後、VirtualBOXが起動しなくなりました。。。（あるある？） powershellを「管理者として実行」で起動します。 Hyper-Vの状態を次のコマンドで確認します。 bcdedit 「hypervisorlaunchtype」がAUTOになってました。←VirtualBoxが起動しなくなったのはこれが原因？ そこで、次のコマンドを入力して、「hypervisorlaunchtype」をoffにします。 bcdedit /set hypervisorlaunchtype off このあと、PCを再起動するとVirtualBOX内の仮想マシンが正常に起動しました。 ただし、これだとDockerがエラーになるので次のコマンドを入力して、「hypervisorlaunchtype」をautoにします。 bcdedit /set hypervisorlaunchtype auto Hyper-Vの有効化/無効化とかコマンド操作するのに抵抗がある人向け VirtualBoxもDockerも両方使いたいけど、コマンドとかは触りたくない人はGUIでHyper-Vを有効/無効の切り替えができるアプリを試すのはいかがでしょうか。 参考記事①：https://qiita.com/picato1123/items/992f84fa41f78dd37030 参考記事②：https://github.com/nuitsjp/HyperV-Switch/blob/master/README-jp.md 上記で記載したコマンドの結果とこのスイッチが対応していることを確認しました。 Hyper-V Switch powershell このスイッチに従い、On/Off設定後にPC再起動します。そうすると、設定が反映されます。 Dockerの起動確認 dockerの起動時、次のリンクのようなエラーが出たが、「WLS２のカーネルを最新化する」と「Linuxディストリビューションをインストールする」を実行すれば直りました。 https://ufirst.jp/memo/2021/08/04/post-2977/ ちなみに、めんどくさい人向けに「WSL 2、有効化とカーネルアップデートをコマンド一発で対応」という記事を見つけました。 （もちろん、私はこちらを試しました） https://news.mynavi.jp/article/20200620-1059833/ コマンド 内容 wsl --install WSL (Windows Subsystem for Linux)の機能を有効化するとともに、必要となるコンポーネントのインストールを行い、システムを再起動するように促す。 wsl --update WSL 2のLinuxカーネルを最新バージョンへアップデートする。 wsl --update --status WSL 2のLinuxカーネルバージョンおよびアップデートを実施した日時を表示する。 wsl --update --rollback WSL 2のLinuxカーネルを1つ前のバージョンへロールバックする。 なんとか、無事にDockerが起動しました。 PC起動時にdockerが立ち上がるのは嫌だったので設定変更しました。 Ubuntuの起動 Dockerが起動している状態でコマンドプロンプトを立ち上げ、下記のコマンドを入力します。 docker run ubuntu ls 起動成功！！ なお、Dockerのダッシュボードから、現在起動しているコンテナを確認することができます。 Docker を利用したアプリケーションの起動 ダウンロードしたソースコード中のDockerfileという名前が存在するディレクトリ内で以下のコマンドを実行することにより、 Web アプリケーションを起動できます。 1. まずDockerfileという名前が存在するディレクトリ内でbuildします。 docker build -t <Dockerイメージ名>:<タグ名(1.0とか)> <Dockerfileのあるディレクトリパス> C:\Users\hoge>docker build -t app-hello:1.0 . [+] Building 59.3s (11/11) FINISHED => [internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 147B 0.0s => [internal] load .dockerignore 0.0s => => transferring context: 52B 0.0s => [internal] load metadata for docker.io/library/node:14 3.9s => [1/6] FROM docker.io/library/node:14@sha256:ab6c8cd32006f8a4c1c795e55ddfbc7f54f5a3fb7318506ecb355cab8f5e7182 49.8s => => resolve docker.io/library/node:14@sha256:ab6c8cd32006f8a4c1c795e55ddfbc7f54f5a3fb7318506ecb355cab8f5e7182 0.0s => => sha256:1a43d3c11106306de19fd422e9da4a6f9b96de147d92c6213d6dbbc395be81b3 11.30MB / 11.30MB 5.5s => => sha256:243ae34810fbd860a43ecf1a7da887386e7a1155913bf13ed95681c98a1cfa84 4.34MB / 4.34MB 1.1s => => sha256:e0dd89382d4f7da3b2be5d5fb74c65bfa1836deecae3c5f88919f44b469025f9 2.21kB / 2.21kB 0.0s => => sha256:31421e72129c508a69ae6b4681101596908a091c9097591b73851fd4470264b7 7.64kB / 7.64kB 0.0s => => sha256:2f0ef4316716c8b8925ba3665932f8bf2cef3b072d82de1aeb269d6b8b61b84c 45.38MB / 45.38MB 15.1s => => sha256:ab6c8cd32006f8a4c1c795e55ddfbc7f54f5a3fb7318506ecb355cab8f5e7182 776B / 776B 0.0s => => sha256:d01c447bcebcc60440b9d84f429ded8ce8d836952f1061c96cce5047230ab696 49.76MB / 49.76MB 15.1s => => sha256:1d07840244ef02090cd7f447e6ab7b021a238b24864e9513e7a37d2891f4fb57 214.44MB / 214.44MB 40.2s => => extracting sha256:2f0ef4316716c8b8925ba3665932f8bf2cef3b072d82de1aeb269d6b8b61b84c 1.8s => => sha256:5037d4710e071cf1f6f5bf24831fab5093d28a1e5fc58b9fff5309bfa193b7bc 35.14MB / 35.14MB 23.9s => => sha256:5df57a36055e9d7d2081a5c4e9310b473498a97c69eba1d2c71778a86f92db0b 4.19kB / 4.19kB 15.9s => => sha256:714346faf07fac8b4573637cb4d6e768b07d7583677b3046dd8d76efff72270a 2.33MB / 2.33MB 17.7s => => extracting sha256:1a43d3c11106306de19fd422e9da4a6f9b96de147d92c6213d6dbbc395be81b3 0.4s => => extracting sha256:243ae34810fbd860a43ecf1a7da887386e7a1155913bf13ed95681c98a1cfa84 0.2s => => extracting sha256:d01c447bcebcc60440b9d84f429ded8ce8d836952f1061c96cce5047230ab696 2.2s => => sha256:6a56afa5a7808121dd05fd91cfe718eb46f8ecc22a34539eca6274e193ba2237 464B / 464B 18.0s => => extracting sha256:1d07840244ef02090cd7f447e6ab7b021a238b24864e9513e7a37d2891f4fb57 7.5s => => extracting sha256:5df57a36055e9d7d2081a5c4e9310b473498a97c69eba1d2c71778a86f92db0b 0.0s => => extracting sha256:5037d4710e071cf1f6f5bf24831fab5093d28a1e5fc58b9fff5309bfa193b7bc 1.5s => => extracting sha256:714346faf07fac8b4573637cb4d6e768b07d7583677b3046dd8d76efff72270a 0.1s => => extracting sha256:6a56afa5a7808121dd05fd91cfe718eb46f8ecc22a34539eca6274e193ba2237 0.0s => [internal] load build context 0.0s => => transferring context: 215.16kB 0.0s => [2/6] WORKDIR /app 0.9s => [3/6] COPY package.json ./ 0.0s => [4/6] COPY package-lock.json ./ 0.0s => [5/6] RUN npm i 4.2s => [6/6] COPY . . 0.0s => exporting to image 0.3s => => exporting layers 0.3s => => writing image sha256:b6b9aee9c9398e7ce0683d4dcfac12aa6489365f0f00c276e71c2fef1d5ac1d8 0.0s => => naming to docker.io/library/wanictf-post:1.0 0.0s Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them 2.「docker images」コマンドでDockerイメージ一覧を確認 C:\Users\hoge>docker images REPOSITORY TAG IMAGE ID CREATED SIZE app-hello 1.0 b6b9aee9c939 8 minutes ago 980MB ubuntu latest ba6acccedd29 2 weeks ago 72.8MB 3.　Dockerコンテナーの起動確認 C:\Users\hoge>docker run -d -p 8080:8080 --name test1 app-hello:1.0 569a2c9b4e843ab54b002491245d493af8f70f43a1c95797a3d8bc259fb160b6 4.ブラウザで確認 http://localhost:8080/にアクセス 5.コンテナーを停止 C:\Users\hoge>docker stop test1 test1 6.コンテナーを削除 C:\Users\hoge>docker rm test1 test1 7.イメージを削除 C:\Users\hoge>docker rmi <IMAGE ID> untagged: app-hello:1.0 ... Good luck

昨今、よくあるdockerコンテナでのシステム構成をとっている場合 コンテナ内で、コマンドを実行したいなどのケースが発生したりします。 Laravelだったら、artisanコマンドを実行したいとか そんなときに使えるのがPHPstormのサービスツールです。 PHPstormにはサービスツールウィンドウというのがあり 開発上利用するツールに対してアクセスして操作ができます(docker, k8s, DBへの接続...) 使い方 1. サービスツールにdockerを追加する デフォルト状態でありそうな気もしますが、無ければ [+]から追加をします。 Mac であれば ⌘8 で Servicesツールウィンドウが開きます 詳しくは Docker サポートを有効にする  2. dockerサービスに接続する 左上の再生ボタンを押してdockerサービスに接続します 3. 対象のコンテナを選択する 入りたいコンテナを選択します。 docker-composeで立ち上げている場合、コンテナがリストでまとまっているので 階層から探してください。 4. Create Terminal でコンテナに入る 右クリックから　[ Create Terminal ] を選択すると ターミナルのタブが開いて コンテナに入れた様子が見れます artisanコマンドも即打てる便利

Dokerfileとは Dockerイメージをコード化したもの メリット ファイルを読むだけでインフラ構成が分かる オリジナルにカスタマイズしたイメージを作成できる 設定ファイルなども変更できる RUN DockerfileからDockerイメージにbuildするときに一回だけ実行されるコマンド # nginxをインストールする場合 RUN apt-get install -y nginx CMD Dockerfileから作成したイメージをコンテナ化するときに実行されるコマンド # nginxをフォアグラウンドで稼働させる場合 CMD ["nginx", "-g", "daemon off;"] exec形式の場合、json配列形式のため、コマンドは必ず「"」ダブルクォーテーションで囲うこと COPY ファイルをイメージに追加するコマンド $ COPY <ホストのファイル名> <コンテナのパス名> ENV 環境変数の指定 DBユーザー名や動作環境名などの設定で使用される # 構文 $ ENV Key:Value # アプリの本番環境を変数に設定 $ ENV APP_ENV="production" # 環境変数の確認（ConfigのENV内に記述されている） $ docker inspect <コンテナ名> 参考教材