ECS(Fargate)でDBマイグレーションを行う - やんばるテック
はじめに この記事ではECS(Fargate)のCDパイプラインに、DBマイグレーション処理を組み込む一例を解説します。 ECS(Fargate)へのデプロイは、ecspressoを使用します。 また、題材はLaravel、CIツールとしてはGitHub Actionsを使いますが、他のフレームワークや、CIツールでも考え方は応用できるかと思います。 目次 はじめに 目次 前提 DBマイグレーションを含む一連のデプロイの流れ DBマイグレーションの前に行うこと ワークフロー例 --watch-containerオプション --overridesオプション GitHub Actions実行結果(抜粋) 前提 本記事で取り扱うECSタスクでは、以下2つのコンテナが起動します。 nginxコンテナ。ベースイメージはnginx:1.20-alpine。 phpコンテナ(Laravelが稼働するコン
Docker Composeの環境変数ではなくsecretsで秘密情報を扱う - Qiita
概要 Dockerの本番環境で秘密情報を使う際に、環境変数を使うことは推奨されてません。 秘密情報を扱うには、コンテナオーケストレーションのsecret supportを使うことが推奨されてます。 Docker Composeには秘密情報を扱うために、secretsがあります。(Docker ComposeのsecretsはDocker Swarmと併用することが前提の機能です) 環境変数で秘密情報を扱う時の問題点 秘密情報を扱う時に、よくある方法として、環境変数を使う方法があります。 (この記事において、秘密情報とはパスワード、APIキーを想定します。) しかし、Dockerのドキュメントhttps://docs.docker.com/get-started/07_multi_container/ には While using env vars to set connection set
Dockerfileのベストプラクティス - Qiita
業務やプライベートでのハンズオンを通して得た知見を元に、dockerfileの実践的な書き方を記載いたしました。 軽量なdocker imageを作る観点とセキュリティーの観点を踏まえた内容になっております。なにか付け足す点などあればコメントいただければと思います。 軽量なimageを作る観点 軽量なimageの使用 Dockerfileでimageを指定する際に、軽量なimageを使用することが進めれている。 docker docsでも代表的な軽量なimageのalpineをおすすめしている。 Whenever possible, use current official images as the basis for your images. We recommend the Alpine image as it is tightly controlled and small in s
GitHub ActionsのイメージビルドをDockerレイヤキャッシュで高速化（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Build images on GitHub Actions with Docker layer caching — Martian Chronicles, Evil Martians’ team blog 原文公開日: 2021-03-11 著者: progapandist (And[re]y Bar[a]nov)、dragonsmith (Kirill Kuznetsov) サイト: Martian Chronicles, Evil Martians’ team blog -- ニューヨークやロシアを中心に拠点を構えるRuby on Rails開発会社です。良質のブログ記事を多数公開し、多くのgemのスポンサーでもあります。 はじめに: 適切なDockerレイヤキャッシングでGitHub Actionsでイメージを構築する方法
AWS Lambda の新機能 – コンテナイメージのサポート | Amazon Web Services
Amazon Web Services ブログ AWS Lambda の新機能 – コンテナイメージのサポート AWS Lambda では、サーバーについて気にすることなくコードをアップロードして実行できます。多くのお客様に Lambda のこの仕組みをご活用いただいていますが、開発ワークフローのためにコンテナツールに投資した場合は、Lambda でのアプリケーションの構築に同じアプローチを使用することが難しくなります。 この問題に対応するため、Lambda 関数を最大 10 GB のコンテナイメージとしてパッケージ化し、デプロイできるようになりました。これにより、機械学習やデータ集約型のワークロードなど、大きな依存関係に頼る大規模なワークロードを簡単に構築してデプロイできます。ZIP アーカイブとしてパッケージ化された関数と同様に、コンテナイメージとしてデプロイされた関数は、同様の操作の
まだdocker-composeのホスト側portを考えるのに疲弊しているの？ 〜IP指定してwell-known ports使い放題、同時に1677万案件回す〜 - 勉強日記
対象読者 問題提起 解決案 -- ポートをバインドするIPを指定する nginx-proxyとの違い macOS固有の問題 Docker Desktop for mac 2.2.x の不具合 127.0.0.1 以外のローカルループバックアドレスがデフォルトで使えない タイトルは釣りです 1677万案件は試してません 対象読者 開発環境を docker-compose で構築しているWebプログラマの人々 複数案件を抱え、ホスト側ポート番号を考えるのに疲弊している人々 HTTP 80 -> 80はとっておいて8080にしたろ！ あの案件で8080を使ったからこっちは10080にしたろ！ 10080の次だからとりあえず20080にしたろ！ うーん、8000！ｗ HMRで8080使いたいけれど使われてるから8081にしたろ！ 問題提起 docker-compose.ymlの例 anken-1/
ローカル開発環境のために外部サービスをモック化する - BASEプロダクトチームブログ
BASE の Service Dev にて主に決済周りのバックエンド開発をしている翠川（@midori44）です。 昨年は PayPal決済の導入 のプロジェクトでメインエンジニアとして携わらせていただきました。 今回は決済周りの開発をしていく中で、社内の開発環境を整えた話をします。 ローカル開発環境での課題 BASEでは現在、BASEかんたん決済 として6つの決済方法を提供しています。 日々の機能開発をしていく中で、すべての決済方法において各機能が正しく動作するかを確認するために、ステージング環境や社内検証用のQA環境だけでなく開発者のローカル環境でも決済をテストできるようになっています。 新機能のリリース時にはもちろん本番環境で実際の決済を通して動作確認するわけですが、開発中のテストの度に本番相当の決済をするわけにはいかないので、各決済代行会社様のほうで用意していただいている検証用サー
コンテナランタイムの仕組みと、Firecracker、gVisor、Unikernelが注目されている理由。 Container Runtime Meetup #2
Docker MeetupとかCloud Native Daysの運営をしながら、無限にスケールするインフラはないかなって、日々もやもやと考えています。 さっそく本題に入っていきましょう。 コンテナってそもそも何ですかっていうと、まず「chroot」というLinuxの機能があって、これはrootディレクトリを特定のディレクトリに切り替えて、そこから下を別のファイルシステムとして確立する、といった技術です。 そこに対して「namespace」という機能で、ユーザー、プロセス、ネットワークを個別に割り当てて、さらにリソースにも制限をかけると、まるでVM（仮想マシン）のように動いて面白いね、というのがコンテナですよ、という説明はよくされると思います。 これを図にしました。 まず、対象のディレクトリに対して「pivot_root」という機能を使ってファイルシステムのルートを作ります。 そのうえで「
docker build と docker-compose build でレイヤーキャッシュが共有できない問題を回避する - ぽ靴な缶
まとめ BuildKit 使ってなくても COMPOSE_DOCKER_CLI_BUILD=1 を使う キャッシュが効いてない CI をいじっていてタイトルの問題に気づいたのが発端。 Cloud Build でキャッシュを使いつつ、ビルドとテストを実行するためにこうしていた。 1 前回のビルドのアプリケーションイメージを docker pull する 2 docker build --cache-from でキャッシュを利用しつつイメージを作る 3 docker-compose run で他のミドルウェア等を起動しつつイメージのテストを実行 4 テストが通れば 2 で作ったイメージを push うまくいくと思っていたけど、2 と 3 で都度アプリケーションイメージがビルドされてしまう。なんでだろなあ、と調べていた。 試していると、COPY を機に docker build と docker
ベースイメージを共通化して docker-compose up を速くする - Shin x Blog
docker-compose で複数サービスを起動する際に時間を要するのが、Docker イメージのダウンロードと展開です。この時間を削減するために、ベースイメージを共通化する方法を試してみました。 本エントリでは、開発環境や CI 環境に docker-compose を利用することを想定しています。 改善前 ここでは、dokcer-compose up(pull) の時間を削減できるかを確認するだけなので、下記のように dynamodb, elasticmq, elasticsearch のみを docker-compose.yml に含めています。 version: "2.0" services: dynamodb: image: amazon/dynamodb-local:1.12.0 ports: - 8000:8000 elasticmq: image: softwaremil
【図解】Dockerの全体像を理解する -前編- - Qiita
この記事は何か イメージやコンテナなどの基本からdocker-compose、docker-machine, docker swarmなどのDocker周りの様々な概念の全体像を整理して、Dockerの仕組みを理解するための記事 前編では「コンテナ、イメージ、DockerHubでのイメージ共有」について書いて行きます。 対象読者 ・Dockerって何？ ・Dockerちょっと勉強したけどDocker compose？ Docker machine？ Docker Swarm？ 色々ありすぎて意味不明 という方 Dockerとは何か Docker社が提供する「コンテナ型仮想化技術」 を実現するプロダクト 仮想化？ PCやサーバといったマシンにインストールされているOS(ホストOS)の上に、別のマシンを仮想的に立ち上げる事 簡単に言うと「パソコンの中に仮想パソコンを起動する」のが仮想化です。
DXを大幅に低下させるDocker for Macを捨ててMac最速のDocker環境を手に入れる - Qiita
※DXはデジタルトランスフォーメーションではなくてDeveloper Experienceの方です 2020/05/26追記 https://qiita.com/nanasess/items/16ab9274c34bdc34e567 を使うことでVagrantを経由せずにDocker for Macの機能だけでMutagenを使うことができるようになりそうです。 パフォーマンスの測定はしていませんが、Docker for Macの設定のみでこの記事の手法と同等の速度が出るようになるかもしれません。 概要 Macでネイティブでの動作とほぼ同等の速度の安定したDocker環境を手に入れることができたので、その知見について公開します。 ものによりますが、最大10倍程度パフォーマンスの向上が見られました。 具体的な手法としてはVirtualBox + Dockerを用います。 設定は2ファイル50
【少しでも楽してコンテナイメージを減らしたかった】コンテナイメージサイズを縮小するためにDive使ってイメージを分析してみた | DevelopersIO
こんばんわ、札幌のヨシエです。 コンテナを使用する時に必要となるものがコンテナイメージです。 このコンテナイメージは小さければ小さいほど正義として扱われ、この正義を通すために人はアレやコレやと試行錯誤を繰り返してコンテナイメージ縮小の旅に出ます。 その旅に持っていけると良いツールとしてDiveを試してみたので紹介させていただきます。 検証用コンテナイメージ 今回の検証は軽量コンテナイメージを元にして、Dockerfileによるレイヤーを重ねる形で動作を確認したいと思います。 利用したコンテナイメージはamazonlinux:latestを使用しました。 % docker images REPOSITORY TAG IMAGE ID CREATED SIZE amazonlinux latest dc34c260f454 5 weeks ago 163MB Diveのインストール brew
コンテナ・セキュリティ入門 脆弱性 - Qiita
コンテナイメージのレジストリでは、脆弱性検査の実装が当たり前になっている。企業でKubernetesなどコンテナを使用するにあたって脆弱性対策がどれほど重要なものか理解するために、脆弱性検査や、関連する国際的な標準について整理した。 脆弱性（ぜいじゃくせい）とは 脆弱性とは、プログラムの動作の不備を悪用される情報セキュリティ上の弱点である。つまり、ソフトウェア上の問題が原因となって生じた欠陥であり、セキュリティホールとも呼ばれる。当然、ソフトウェア開発者は、脆弱性を産まないように細心の注意を払ってコード開発を進めるが、開発者が利用するオペレーティングシステムのライブラリやパッケージに含まれることもある。そのような事情から、開発者の責任範囲外に原因がある場合も多くある。 潜在的な脆弱性を突いた新たなクラッキングの手口が、時間の経過ともに発見される。そのことから、開発当初はコードに脆弱性は無い
Amazon ECS ScheduledTaskで実現するスマートなDockerベースのバッチ実行環境 - コネヒト開発者ブログ
こんにちは。インフラエンジニアの永井(shnagai)です。 コネヒトでは、開発環境に続き、続々と本番サービスにもDockerを導入しています。 今回は、中々運用が大変なcronでスケジュール管理するような定期的なバッチ処理を、Amazon ECSのScheduledTaskを使ってDocker駆動な環境で構築した話です。 他の方法との比較やどのように実現しているのかについて紹介したいと思います。 今回対象とするバッチの種類 今回対象とするバッチ処理は、俗に言うスケジュール系のバッチ処理で、毎日00時00分や10分毎にサイクル起動等、事前に定義した時間に正確に動くことが期待されているものです。 ※ジョブキュー形式のバッチだと、AWS BatchやEBのWorkerもしくは、SQS + Cron on EC2で処理するほうがスマートかと思います。 実行方式の選定 上記要件のバッチを実現する基
1つのDockerfileだけでGoの開発環境(ホットリロード)と本番環境(マルチステージビルド)を記述する - Qiita
こんにちは。po3rinです。今回はDocker Meetup Tokyo #29 (Docker Bday #6)で少し話題になった小ネタです。タイトル通りDockerfile1つでGoの開発環境(ホットリロード)と本番環境(マルチステージビルド)を記述する方法を紹介します。今回は「この方法をおすすめします！」というよりかは「こういう方法もあるよー」という紹介なので、開発の状況に合わせて方法を選んでいくと良いでしょう。 イントロ 開発環境用と本番環境でイメージビルド過程を分けるモチベーションとしては、開発環境用はホットリロードしたいけど、本番はビルドしたバイナリだけを使いたいという思いなどがあります。 これらを２つのDockerfileに分ける場合、同じディレクトリ階層に「Dockerfile」という名前のファイルを２つ置けません。これに関して、下記の記事のようにdocker build
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - clemenko/best_practices: best practices for docker ee
Docker ロギングのベストプラクティス
OW2 on Twitter: "docker-compose.override.yml を .gitigore （ローカル or グローバル）に書いて設置 https://t.co/35o6SdO7ks"
Docker Buildにおけるリードタイム短縮のための3つの改善ポイント | PLAID engineer blog
