nginx コンテナ起動時に環境変数を渡す方法【2023 年版】
はじめに nginx コンテナを建てる際に、どうやって設定ファイルに環境変数を渡すかやってみたのでまとめてみる。 今回使用したものは以下になる。 Docker Engine Docker Desktop v4.16.2 nginx base image nginx:1.23.3 結論 最初に結論を言うと、以下 2 つを行えば実現できる。後ほど順を追って説明する。 設定ファイル用のテンプレートを作成し ${ENV} 形式で記載 コンテナ起動時に環境変数を渡す（docker run --env） 🚫 Dockerfile の CMD 命令で envsubst している記事が散見される が v1.19 以降の公式のイメージでは不要になった。 そういう意図も込めてタイトルに 【2023 年版】 などと付けてみた笑 設定のテンプレートファイルを作成 公式の nginx イメージを使う場合、デフォル
ちょうどよいビルドツールEarthlyの紹介
ちょうどよいビルドツールEarthlyの紹介 ビルドツールと呼ばれるものは昔から現代まで使われているMake、JavaやKotlinでは一般的なGradle、Googleで使われていたものをOSS化したBazelあたりが有名です。他にも様々なビルドツールが存在するのですが、知名度は低いものの最近自分が注目しているEarthlyというビルドツールを紹介します。 まずEarthlyの特徴をBazelやGradleといった他のビルドツールと比較して簡単に紹介します。 Dockerfile + Makefile風のDSL どんなビルドツールでも基本的には独自DSLでビルド設定を書くことになりますが、EarthlyはDockerfileとMakefileを合体させたようなDSLとなっており、他のビルドツールと比較して分かりやすい方だと思います。このDSLについては後述しますが、このサンプルコードでも
Linuxコンテナの「次」としてのWebAssembly、の解説
はじめに WASMをブラウザの外で動かすトレンドに関して「Linuxコンテナの「次」としてのWebAssemblyの解説」というタイトルで動画を投稿したのですが、動画では話しきれなかった内容をこちらの記事で補完したいと思います。 2022年もWebAssembly(WASM)の話題が多く発表されましたが、そのひとつにDocker for DesktopのWASM対応があります。FastlyやCloudflareもエッジ環境でWASMを動かすソリューションを持っていますし、MSのAKS(Azure Kubernetes Service)でもWASMにpreview対応しています。WASM Buildersでも2023年のWASMの予想としてWASMのアプリケーションランタイム利用に関して言及されました。 WASMといえば元々ブラウザ上で高速にC++のコードなどを実行するところから始まっている
Java 17：OpenJDKのコンテナ対応における新機能 - 赤帽エンジニアブログ
Red Hat で Java Platform Advocate として OpenJDK を担当している伊藤ちひろ（@chiroito）です。 この記事は、Red Hat Developerのブログ記事、Java 17: What’s new in OpenJDK's container awareness | Red Hat Developer の翻訳記事です。 OpenJDKは、以前からLinuxコンテナ（DockerやPodman、またKubernetesのようなコンテナオーケストレーションフレームワークなど）を意識してきました。コンテナ対応とは、OpenJDKがコンテナ内で動作していることを検出することを意味します。この記事では、コンテナ対応がなぜ有用なのか、OpenJDKのその領域で最近何が変わったのか、そして、開発者がJVMの設定決定方法について理解を深めるために利用できる診断
Advanced multi-stage build patterns
Multi-stage builds feature in Dockerfiles enables you to create smaller container images with better caching and smaller security footprint. In this blog post, I’ll show some more advanced patterns that go beyond copying files between a build and a runtime stage, allowing to get most out of the feature. If you are new to multi-stage builds you probably want to start by reading the usage guide firs
DockerfileのCMDとENTRYPOINTを改めて解説する - Qiita
TL;DR dockerで、コンテナ内で実行するプロセスを指定してのコンテナ起動方法は以下のとおり。 docker run <コンテナ指定> <プロセス指定> [ <プロセスに与える引数指定> ] docker runで、起動するプロセスを毎回指定するのが面倒で、決まった特定のプロセスを指定したいなら、以下のどれかを選択する。 (ENTRYPOINTを指定しない場合) DockerfileのCMD項目でプロセスおよびそれへの引数を指定する。この場合、docker run <コンテナ指定> [RET] のようにプロセス指定を省略して起動したときに、CMD項目で指定した内容が起動するプロセスのおよびそれへの引数の指定となる。 docker run <コンテナ指定> <プロセス指定> [ <プロセスに与える引数指定> ] <----------CMDで省略値を与えられる---------> (E
Dockerでマストドンやってたら、遮断したはずのポートが丸見えだった件 | Divide et impera
みんなマストドンをやっているだろうか？ 僕はやっている。 インスタンス管理をやっている。 こんなふうに運用していた conoHaのVPS CentOS7.3 Dockerで運用している ちなみにDockerは今回が初めて本格的に触った。 マストドンは裏側では3000ポートと4000ポートで待ち受けている。 3000の方は普通のWEB 4000の方はAPIを担当している。 HTTPサーバーであるnginxが、httpの80とhttpsの443で受け取ったら、 それぞれ3000と4000に送りつけている リバースプロキシという技だ。 通常、公開用のhttpとhttpsのポートだけ開けておく。 もちろん僕もそのようにしていた。 CentOS7以降はiptablesではなくfirewalldというファイアウォールのソフトウェアでポートの開け閉めを管理している。 firewalldで、許可するポート
Docker の iptables 設定
Docker のネットワークまわりの理解を深める一環として iptables について整理します。 全体として Iptables Tutorial がとても参考になりました。 iptables とは iptables の構成要素 Docker デーモン起動時の iptables Docker コンテナ起動時の iptables 環境: # OS $ cat /proc/version Linux version 4.14.13-1-ARCH (builduser@heftig-32336) (gcc version 7.2.1 20171224 (GCC)) #1 SMP PREEMPT Wed Jan 10 11:14:50 UTC 2018 # iptables $ iptables --version iptables v1.6.1 # Docker $ docker version
docker-compose not showing logs for all containers · Issue #4837 · docker/compose
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community. Pick a username Email Address Password Sign up for GitHub By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails. Already on GitHub? Sign in to your account
今日から始める人のためのKubernetes on AWSベストプラクティス - Qiita
今年一年Kubernetes on AWSをやってきて、kube-awsメンテナ目線で、「今日から、できるだけ楽に、安定して本番運用」するための個人的ベスト・プラクティスをまとめておきます。 TL;DR EKSはまだプレビュー申込の段階。実際に動くものがあるかもわからない。 EKSとkops、kube-aws、kubesprayなどは組み合わせて使うもの。代替えにはならない。 SaaSありなら分散ログ、分散トレース、リソースモニタリングはDatadogに寄せると運用が楽 istioは安心して本番運用できるフェーズではない(Service Meshが必要なら、まだLinkerdのほうがよい) アプリケーションにPrometheusエンドポイントを生やしてメトリクスを取れるようにすべき アプリケーションはOpenTracingやZipkin、Jaegerなどのトレーサを組み込み、Zipkin
Docker + Linuxでいい感じに自宅・小規模オフィス用ルータを作る - Qiita
年末年始になると自宅のネットワーク周りをいじりたくなるmizutaniです．1年くらい前にミラーリングできるスイッチを格安で手に入れてはしゃいで自宅ネットワークの監視環境を作ったんですが，今見直してみるとわりと複雑な構成で，これをどうにか整理できないかと昨年末に思い立ちました．機器の構成はなるべくシンプルにするとともにどうせなら今風な作りにしようということで，Docker + Linuxで構成するPCルータを作ってみました． 設計 原則 サービスのモジュール化 Linux kernelにやらせなければならない仕事を除き，各サービスをなるべく独立して動かせるようにします． 市販のブロードバンドルーターなどと比べ，Linuxを入れたマシンは非常に自由度が高いためなんでもできますが，そのために環境が"汚れて"しまうという問題が有ります 細かい変更を続けるうちにサービスや保存してあるファイルの依存
KubernetesでGPUを使う
KubernetesでGPUを使う 一般的なWebアプリケーションと比較してMachine Leaning（ML）は複雑なインフラを要求する．Data processingを行う環境やModelのTraining/Validationを行う環境，実際にサービスからModelを利用するためのServingの環境といった複数の異なる環境が必要であり，WorkloadによってはCPUだけではなくGPUも必要になる．これらを効率的に扱うためのインフラを構築・運用するのは容易でなくGoogle and Uber’s Best Practices for Deep Learningにあるようにこれまで培われてきたDevOpsの知見を結集していく必要がある． このような複雑なMLのインフラとしてContainerとKubernetesが利用されることが多くなってきている．特に複数の環境間のPortabi
Dockerコンテナ時代の第一章の終わり、そして第二章の展望など － Publickey
コンテナ型仮想化の技術や実装はDockerが登場する以前から存在していたとはいえ、IT業界で本格的にコンテナの活用が始まったと言えるのは、やはり2013年3月に当時のdotCloudからDockerが登場したことがきっかけでしょう。 そうして始まったコンテナ時代の第一章は今年2017年、コンテナの標準仕様がOpen Container Initiativeによって策定完了し、コンテナオーケストレーションの事実上の標準がKubernetesに決まったことで基盤技術の基本要素がおおむね固まり、一つの区切りがついたように見えます。 そして今後は、この基盤技術を用いたコンテナによる分散アプリケーションのための様々なサービスや開発、テスト、デプロイ、本番環境に対応したツールやサービス実行環境などのソリューションが登場し、競う段階へ入っていくのではないでしょうか。 この記事では、Docker登場から現
Amazon ECS ScheduledTaskで実現するスマートなDockerベースのバッチ実行環境 - コネヒト開発者ブログ
こんにちは。インフラエンジニアの永井(shnagai)です。 コネヒトでは、開発環境に続き、続々と本番サービスにもDockerを導入しています。 今回は、中々運用が大変なcronでスケジュール管理するような定期的なバッチ処理を、Amazon ECSのScheduledTaskを使ってDocker駆動な環境で構築した話です。 他の方法との比較やどのように実現しているのかについて紹介したいと思います。 今回対象とするバッチの種類 今回対象とするバッチ処理は、俗に言うスケジュール系のバッチ処理で、毎日00時00分や10分毎にサイクル起動等、事前に定義した時間に正確に動くことが期待されているものです。 ※ジョブキュー形式のバッチだと、AWS BatchやEBのWorkerもしくは、SQS + Cron on EC2で処理するほうがスマートかと思います。 実行方式の選定 上記要件のバッチを実現する基
RDBへのバッチクエリクライアントタスク
本記事は個人の意見であり、所属する組織の見解とは関係ありません。 こちらは AWS Fargate Advent Calendar 2017 の 12/4 分の記事です。 AWS Fargate を利用することで、従来のサーバーレス環境では工夫が必要であった長時間処理（業務処理的なバッチ）を、容易にサーバーレス環境で実現することが可能となりました。今回は、参考例として DB に対して長時間クエリが可能な仕組みを作成してみたいと思います。 構成概要 AWS Fargate 上で長時間タスクを実行する仕組みとして、下記の構成を作成してみます。 今回は SQL を実行する仕組みですが、メイン処理次第ではさらに複雑な処理の実行も可能と思っています。 Amazon S3 タスクのメイン処理の Python スクリプト、検索結果ファイルを格納します。 Amazon Aurora クエリ先のデータベース
Re: Dockerに載せたサービスをホットデプロイする - okzkメモ
こちらを拝見したところ、やりたいコトはdocker1.12のswarmモードで解決するんじゃないかなー、と思ってみたので試してみたテスト。 h3poteto.hatenablog.com とりあえず、最新版のdocker(1.12)をインストールです。 手元の環境はCentOS7なので、インストールガイドに従ってゴニョゴニョと。 んでもって、swarm初期化。 # docker swarm init 今回1台だけなので、ノード追加は行いません。 次に実験用にnginxのサービスを立ち上げます。 ポイントはimage差し替え時に「停止→起動」の順番で動くので、あらかじめレプリカ数を2にしておいて、ちゃんとローリングで切り替わるようdelayを設定することです。 # docker service create --update-delay 20s -p 80:80 --name test --
Docker 1.12 swarm mode - round robin inside and out
Swarm mode built in with Docker 1.12 My excellent colleague Dave Wybourn recently blogged about Docker Swarm in this post. Since then, Docker 1.12 has been released and swarm functionality has been integrated into the main Docker engine. Release 1.12 of the Docker engine has a lot of compelling new features. You can read about them in the official release notes on GitHub. On my current project, we
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[表示が崩れる場合ダウンロードしてご覧ください] 2018年のDocker・Moby![[表示が崩れる場合ダウンロードしてご覧ください] 2018年のDocker・Moby](https://cdn-ak-scissors.b.st-hatena.com/image/square/715e0f3b75d501f9c2c133c4f946c4c6109513f0/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fdocker-and-moby-in-2018-180419034237-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
小さく始める Docker container の deploy
Docker Compose入門～今日から始めるComposeの初歩からswarm mode対応まで
