タイトル通りです。 docker-compose.ymlがあるディレクトリで、下記のコマンドを使用しdockerk-composeしようとすると、、 docker-compose up --build 下記の例外が出て怒られてしまいました。。 docker.errors.DockerException: Error while fetching server API version: ('Connection aborted.', FileNotFoundError(2, 'No such file or directory')) [8136] Failed to execute script docker-compose こんなときはとりあえず、下記コマンド打ってみましょう。 docker ps 一行も表示されない。。 ということはコンテナが起動していませんね！ $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES docker for Desktop開くと、下記のコマンド打ってねとのこと。 $ docker run -d -p 80:80 docker/getting-started 再度、docker psを試してみます。 $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 1e554004b2de docker/getting-started "/docker-entrypoint.…" 7 seconds ago Up 6 seconds 0.0.0.0:80->80/tcp awesome_ritchie CONTAINER IDが出力されましたね！ 再度docker-composeしてみましょう。 docker-compose up --build 出力結果が長かったので途中は省きましたが、無事docker-compose up --build できました！ Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them Creating python-kaggle-start-book_jupyter_1 ... done 意外と初歩的なことで詰まったりしますよね。 困ったら、docker psくらいでいいと思います。 以上です！ここまで読んでいただきありがとうございました！

概要 GitHubActionsを利用したテストワークフローの構築について社内布教用にまとめてみた 経緯 @ucan-lab さんのハンズオンに参加して個人的に導入はしているがチーム内で技術共有をしてなかったので布教用としてまとめることにしました なお、今回のworkflowについては以下のハンズオン資料を流用させていただいています。 解説 GitHub リポジトリの [Actions] タブに表示されるワークフローの名前。 name: Laravel Testing on:ワークフローを発火させるトリガーを指定します pull_request: PRが作成されたタイミングをトリガーします branches:特定のブランチに対してのPRに対してだけトリガーします（デフォルトは全てのブランチが対象です） on: pull_request: branches: - main runs-on: ubuntu-latest: 実行する仮想マシンを指定します（今回はubuntuの最新版) steps:ジョブのステップをグループ化する uses: actions/checkout@v2 : リポジトリをチェックアウトし、ワークフローがアクセス可能にする jobs: laravel-testing: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name :GitHubに表示するステップの名前 run:コマンドを実行するようにジョブに指示を出します steps: - name: Docker Version run: docker version run: |:複数コマンド順に実行します docker-compose exec -T :擬似TTY（疑似端末）への割り当てを無効にする ttyとは、標準入出力となっている端末デバイス(制御端末、controlling terminal)の名前を表示するUnix系のコマンドである。元来ttyとはteletypewriter（テレタイプライター）のことを指す。 steps: - name: OS Version # -T 擬似TTY(標準出力の接続先デバイス)への割り当てを無効 run: | docker-compose exec -T app cat /etc/os-release docker-compose exec -T app cat /etc/debian_version 全体 .github/workflows/laravel-testing.yml name: Laravel Testing on: pull_request: branches: - main jobs: laravel-testing: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: Docker Version run: docker version - name: Build Docker Images run: docker-compose build - name: Create & Start Docker Containers run: docker-compose up -d - name: OS Version # -T 擬似TTY(標準出力の接続先デバイス)への割り当てを無効 run: | docker-compose exec -T app cat /etc/os-release docker-compose exec -T app cat /etc/debian_version - name: PHP Version run: docker-compose exec -T app php --version - name: Composer Version run: docker-compose exec -T app composer --version - name: Install Dependencies run: docker-compose exec -T app composer install - name: Laravel Version run: docker-compose exec -T app php artisan --version - name: Laravel Setting run: | docker-compose exec -T app cp .env.example .env docker-compose exec -T app php artisan key:generate - name: Laravel Migrate Testing run: docker-compose exec -T app php artisan migrate - name: Laravel Rollback Testing run: docker-compose exec -T app php artisan migrate:refresh - name: Laravel Seeding Testing run: docker-compose exec -T app php artisan db:seed - name: Laravel PHPUnit Testing run: docker-compose exec -T app php artisan test

リモートのアルバイトで始めた仕事が、長期化、長時間化。 Slackでの開発者との仕事で、文字が小さくスレッドやチャンネル迷子は相変わらず日常茶飯事。 Slackの中で、最初に覚えたマークダウンはまた、コードをインライン表示すること ` バッククォート` 最近、Qiitaでのありがたい編集のフィードバックで覚えた コードブロックの書き方 (空行) ``` code.... ``` (空行) コーディングとは程遠いですが、新しいトリックを覚えるのはシンプルに楽しいなと思えた瞬間でした。 さて、今回はこちらの翻訳のご紹介です。 こちらに関連し以前ご紹介した 安全なNode.jsのためのDockerイメージ構築のステップバイステップのチュートリアルの翻訳も、ぜひ参照してみてください。 では、今回のお題をご案内しますね。 Docker for Node.jsデベロッパ：セキュリティを失敗させないために知っておくべき5つのこと Liran Talリランタル 2021年1月25日 Dockerは、コンテナイメージのダウンロード数が合計で500億を超えています。Docker Hubでは何百万ものアプリケーションが利用できるため、コンテナベースのアプリケーションは人気があり、アプリケーションを簡単に使用および公開が可能です。 Docker Node.js のWebアプリケーションを構築する単純な方法(qiita翻訳）には、多くのセキュリティリスクが伴う可能性があります。では、Node.jsデベロッパにとってセキュリティをDockerで考慮するにはどうすればよいでしょうか。 Docker for Node.jsとDockerイメージの構築の要点に飛び込む前に、このトピックに関するよくある質問を見てみましょう。 Node.jsアプリケーションをdockerizeするにはどうすればよいですか？ DockerコンテナでNode.jsアプリケーションを実行するには、プロジェクトのディレクトリをコピーして、必要なnpmパッケージをすべてインストールするだけでよいのですが、セキュリティや生産に関する多くの懸念事項を見逃す可能性があります。 Dockerを使用したNode.jsWebアプリケーションのコンテナ化では、正しいDockerベースイメージの選択から、多段ビルドの使用、シークレットの安全な管理、本番関連のフレームワーク設定の適切な有効化まで、すべてをカバーしています。 この記事では、Webアプリケーションに適切なNode.js Dockerベースイメージを選択することの影響をよりよく理解するために必要な情報に焦点を当て、アプリケーションで利用できる最も安全なDockerイメージを見つけるためのガイドを提供します。 DockerはNode.jsデベロッパにとってどのように役立ちますか？ Node.jsアプリケーションをコンテナーにパッケージ化すると、ランタイム、構成、OSレベルの依存関係、およびWebアプリケーションがさまざまなプラットフォームやCPUアーキテクチャーで実行するために必要なすべてのものを含む完全なアプリケーションをバンドルできます。これらのイメージは、コンテナーイメージと呼ばれるデプロイ可能なアーティファクトとしてバンドルされています。これらのDockerイメージは、簡単に再現可能なビルドを可能にするソフトウェアベースのバンドルであり、Node.jsデベロッパにすべての環境で同じプロジェクトまたは製品を実行する方法を提供します。 最後に、Dockerコンテナを使用すると、デベロッパは、特別な権限を必要とせずに、またはプロジェクトを実行するための専用環境をセットアップすることなく、新しいプラットフォームリリースやその他の変更をより簡単に試すことができます。 アプリケーションに適したNode.jsのDockerベースイメージを選択する Node.jsのプロジェクトでDockerイメージを作成する場合、Docker Hubから引っ張ってきた別のDockerイメージをベースに、独自のアプリケーションイメージを構築します。これはベースイメージと呼ばれるものです。ベースイメージは、これから構築するNode.jsアプリケーション用の新しいDockerイメージの構成要素になります。 ベースイメージの選択は、Dockerイメージのビルド速度から、Webアプリケーションのセキュリティやパフォーマンスまで、すべてに大きく影響するため、非常に重要です。DebianやUbuntuをベースとした本格的なオペレーティングシステムイメージを選択するのは、このイメージで利用可能なすべてのツールやライブラリを活用することができるでしょう。 しかし、これには代償があります。ベースとなるイメージにセキュリティ上の脆弱性があると、新しく作成するイメージもそれを引き継ぐことになります。なぜ、多くの脆弱性を含む大きなベースイメージをデフォルトにした悪条件でスタートしたいのでしょうか？ ベースイメージを見ると、セキュリティ脆弱性の多くは、このベースイメージが使用しているOS（Operating System）層に属しています。Snykの2019年の研究「Shifting Docker security left」では、OS層がもたらす脆弱性は、選択する種類によって大きく異なることが示されました。 ちなみにこれは、利用を検討するすべてのベースイメージに対して、当てはまる懸念事項です。例えば、2020年の「オープンソースセキュリティの現状」レポートから、最新のイメージビルドを持つ上位のDockerイメージを紹介すると、Dockerのベースイメージには一貫してデフォルトでセキュリティの脆弱性が含まれていることがわかります。 2. 開発中にNode.jsのDockerイメージをスキャンする 他のイメージを基にDockerイメージを作成したり、それらを再構築することは、新たな脆弱性をもたらす可能性がありますが、あなたがその上に立つための方法があります。 Dockerイメージのビルドプロセスを、他の開発関連の活動と同じように扱います。あなたが書いたコードをテストするのと同じように、あなたがビルドしたDockerイメージもテストすべきです。 これらのテストには、Dockerfileにセキュリティ上の落とし穴やその他の悪いパターンがないことを確認するための静的ファイルチェック（別名linters）が含まれます。Dockerイメージのセキュリティのベストプラクティスで、これらの概要を説明しました。もしあなたがNode.jsアプリケーションのでエロっぱならなら、このステップバイステップの「DockerでNode.jsウェブアプリケーションをコンテナ化する10のベストプラクティス」を読みたいと思うでしょう。 git リポジトリを Snyk に接続することも優れた選択です。SnykはGitHub、GitLab、Bitbucket、Azure Reposとのネイティブな統合をサポートしています。gitとの統合を行うことで、プルリクエストをスキャンし、セキュリティの脆弱性を発見した場合には、セキュリティ情報を注釈として付与することが可能になります。これにより、プルリクエストが新たなセキュリティ上の脆弱性をもたらす場合、ゲートを設け、マージを拒否することができます。 継続的インテグレーション (CI) に柔軟性が必要な場合、または密接に統合された開発者エクスペリエンスが必要な場合は、Snyk CLI をご利用ください。 CLIを使用すると、Dockerコンテナ・イメージを簡単にテストすることができます。例えば、ローカルでDockerイメージを構築して、タグ付けしているとします。 nodejs:notification-v99.9—次のようにテストします: Snyk CLIをインストール: $ npm install -g snyk Snyk CLI が自動でAPIトークンを自動的に取得: $ snyk auth ローカルのベース画像をスキャン: $ snyk container test nodejs:notification-v99.9 テスト結果は、脆弱性を導入したパスであるCVEに関する情報とともに画面に出力されるので、どのOSの依存関係が原因なのかを知ることができます。 以下は、node:15のDockerのベースイメージをテストするための出力例です。 : ✗ High severity vulnerability found in binutils Description: Out-of-Bounds Info: https://snyk.io/vuln/SNYK-DEBIAN9-BINUTILS-404153 Introduced through: dpkg/dpkg-dev@1.18.25, libtool@2.4.6-2 From: dpkg/dpkg-dev@1.18.25 > binutils@2.28-5 From: libtool@2.4.6-2 > gcc-defaults/gcc@4:6.3.0-4 > gcc-6@6.3.0-18+deb9u1 > binutils@2.28-5 Introduced by your base image (node:15) ✗ High severity vulnerability found in binutils Description: Integer Overflow or Wraparound Info: https://snyk.io/vuln/SNYK-DEBIAN9-BINUTILS-404253 Introduced through: dpkg/dpkg-dev@1.18.25, libtool@2.4.6-2 From: dpkg/dpkg-dev@1.18.25 > binutils@2.28-5 From: libtool@2.4.6-2 > gcc-defaults/gcc@4:6.3.0-4 > gcc-6@6.3.0-18+deb9u1 > binutils@2.28-5 Introduced by your base image (node:15) Organization: snyk-demo-567 Package manager: deb Target file: Dockerfile Project name: docker-image|node Docker image: node:15 Platform: linux/amd64 Base image: node:15 Licenses: enabled Tested 412 dependencies for known issues, found 554 issues. Base Image Vulnerabilities Severity node:15 554 56 high, 63 medium, 435 low Recommendations for base image upgrade: Alternative image types Base Image Vulnerabilities Severity node:current-buster-slim 53 10 high, 4 medium, 39 low node:15.5-slim 72 18 high, 7 medium, 47 low node:current-buster 304 33 high, 43 medium, 228 low We have a Snyk CLI Cheatsheet, showing some of the magic you can do with it, and you can also find more information on how to get started with the Snyk Container CLI in our documentation. Snyk CLI Cheatsheetでは、Snyk CLIでできる便利な機能の一部を紹介しています。また、Snyk Container CLIを使い始める方法についての詳細な情報は、当社のドキュメントでご覧いただけます。 3. Dockerイメージに含まれるNode.jsのランタイムの脆弱性を修正する Dockerコンテナ・イメージのリスクを管理する際に見落としがちなのが、アプリケーション・ランタイムそのものです。Java用のDockerを実践している場合でも、Node.jsウェブアプリケーション用のDockerを実行している場合でも、Node.jsアプリケーションランタイムそのものが脆弱である可能性があります。 Node.jsのセキュリティリリースとNode.jsのセキュリティポリシーに注意し、従う必要があります。手動でこれらをフォローする代わりに、Snyk を活用して Node.js のセキュリティ脆弱性を見つけることもできます。 Node.jsのさまざまなベース画像タグのセキュリティ脆弱性について、より多くのコンテキストを提供するために、Snyk CLIでそれらのいくつかをスキャンし、次の対数スケールチャートに結果をプロットしてみました: このようなことがわかりました: 1. node:latestとも呼ばれるデフォルトの node base imageタグは、500以上のセキュリティ脆弱性をバンドルしていますが、Node.jsランタイム自体にも2つのセキュリティ脆弱性を導入しています。現在、Node.js 15バージョンを実運用しており、パッチや修正を行っていない場合は、これは懸念事項となります。 2. node:alpine base image タグは、ベースイメージに脆弱な OS の依存関係をバンドルしていないかもしれません-これが青いバーがない理由です-が、最新の Node.js ランタイム（version 15）の脆弱なバージョンを含んでいることになります。 3. サポートされていないバージョンのNode.js（例えば、Node.js 10）を使用している場合、それは脆弱であり、セキュリティアップデートを受け取っていないことがわかります。 この記事を書いている時点で、リリースされている最新版であるNode.js version 15を選択した場合、実際にはこのコンテナ内の561のセキュリティ脆弱性だけでなく、Node.jsランタイム自体の2つのセキュリティ脆弱性にも晒されることになります。 このパブリック・イメージのテストURLでDockerスキャンのテスト結果を見ることができます。あなたが使用している他のNode.jsベースイメージタグを、この無料で公開されているDockerスキャンサービスでテストすることをオススメします。 SnykはDocker HubとDocker Desktopにおけるコンテナスキャンをサポートしており、セキュリティは今やDockerのワークフローに不可欠な要素となっています。また、SnykはDockerの公式イメージの公式セキュリティプロバイダでもあります。実際、Dockerを開発プラットフォームとして使用している方は、Docker Desktop with Snykと新しいDocker脆弱性チートシートをご参照ください。 すでにDockerのユーザーアカウントをお持ちの場合は、それを使ってSnykに接続し、Docker Hubリポジトリをすぐにインポートすることができます。 4. Node.jsアプリケーションにデプロイされたDockerイメージの監視 Dockerイメージを構築したあと、おそらくイメージを追跡するDockerレジストリにプッシュし、機能的なコンテナアプリケーションとしてデプロイし、起動できるようにしますよね。 なぜDockerのベースイメージを監視する必要があるのか？ ベース画像のスキャンと修正で、これまで説明したセキュリティガイドラインをすべて実践しているのであれば、それは素晴らしいことです。しかし、新しいセキュリティの脆弱性は常に発見されていることを心に留めておいてください。今、イメージに78件のセキュリティ脆弱性があったとしても、明日の朝、新しいCVEが報告され、運用中のコンテナに100件の影響がないとは限りません。そのため、コンテナイメージのレジストリ（コンテナのデプロイに使用しているイメージ）を監視することは、セキュリティ問題をすぐに発見し、修正できるようにするために非常に重要です。 もしあなたが有料のDocker Hubレジストリをイメージに使用しているなら、Docker HubにSnykによるDockerセキュリティスキャンが統合されているのを既にご存知かもしれません。 また、Snykアプリから多くのDockerイメージレジストリと直接統合することができます。例えば、Docker Hub、ACR、ECR、GCR、Artifactoryからイメージをインポートすると、Snykがこれらを定期的にスキャンし、見つかったセキュリティ問題についてSlackや電子メールで警告をうけることができます。 5. セキュリティガイドラインとプロダクショングレードの推奨に従って、安全で最適なNode.jsのDockerイメージを作成します。 これまでセキュリティガイドラインについてここまで読みすすめていただき、ありがとうございました！ あなたはJavaのデベロッパですか？こちらもぜひ、参照してください。 Javaデベロッパが知るべきDockerセキュリティ５つの大切なこと 10 best practices to containerize Node.js web applications with Docker Dockerでnode.jsウェブアプリケーションをコンテナ化するための10のベストプラクティス - もしあなたがNode.jsデベロッパなら、Node.jsアプリケーション用に安全でパフォーマンスの高いDockerベースイメージを構築する方法を示すこのステップバイステップのチュートリアルは、とても気に入るでしょう。 SnykとDocker IDを使用して、コンテナイメージのテストと修正を開始するにはこちらへ 最後まで読んでいただき、ありがとうございました！！！ Contents provided by: Jesse Casman, Fumiko Doi, Content Strategists for Snyk, Japan, and Randell Degges, Community Manager for Snyk Global