あらすじ 公衆WiFiに繋いだ状態でいつものように docker container run -p 8080:80 nginx のような感じでDockerコンテナを動かしていたら、外部からリクエストを受信した。 ファイアウォールを設定し、外部からのアクセスを拒否しているはずなのになぜアクセスできたんだ... 環境 Docker desktop for mac with apple silicon 4.21.0 何が起きた? Dockerはデフォルトの設定では-p 8080:80のようにポートマッピングするとファイアウォールの設定を書き換え、外部からそのポートへのアクセスを許可するようになっている。 その結果LAN内の他のPCから対象ポートにアクセス出来てしまう。 ちなみにこれはDocker公式からも注意が出ている。 Publishing container ports is insecur

使っているパソコンを変えても、開発環境を揃えたい時はDockerを使うと便利。ということでDockerでPython環境を作って色々なところで使いまわせるようにします。Tokyo AEC Industry Dev Groupというミートアップグループで行う（行った）ハンズオンワークショップの内容となっています。こちらDockerを初めて使う初心者用の記事となります。 ワークショップ自体は録画してYoutubeにアップしてあります。そちらもよろしければどうぞ。 Dockerとは Dockerとはシステム開発や運用に最近よく使われるコンテナ技術を提供するサービスの一つです。コンテナとは、アプリケーションの実行に必要な環境をパッケージ化して、いつでもどこからでも実行するための仕組みです。自分のコンピュータの環境を汚すことなく、隔離された環境を作ってそこでプログラムを動かすことができるのでトライア

DockerでGoを動かす DockerをGoで動かすのがゴールですが、その中で必要となる事、今回は"マルチステージビルド"について学習しました。 1. 要件 マルチステージングビルドを使用する REST APIを使用する 2. マルチステージングビルド 主参考: マルチステージビルドの利用 2-1. マルチステージングビルドとは Multi-Staging Build(Multi-Stage Build) 直訳すると、複数のステージを用いたビルド Docker17.05以上で利用できる新機能 可読性・保守性を保ちながらDockerfileを最適化するのに苦労している人の役に立つ 2-2. マルチステージングビルドの目的 アプリケーションの実行に必要なもののみをビルドすること そのために複数ステージを用いる 結果、イメージサイズが小さくなり、本番環境の運用のパフォーマンスが向上する 3.

上記の表の参考記事 Windows windowsサーバー専用の環境にしたい場合に使用する Slimの有無 公式とDebian系にはSlimがついているものが用意されている。 Slimがついているイメージを使用すると使用頻度の低いパッケージは除外される。 イメージの選び方 公式パッケージを選ぶのは容量に制限が特になかったり、マルチステージビルドにすることで気にする必要性が減る場合などで使用するといい。 Alpine LinuxやSlimはサクッと環境を作りたい場合に良さそう。 参考記事 追記 安易にAlpine Linuxを使うのはやめた方が良さそう。（目的に合わせて使おうというだけ） Alpine Linuxが軽量というイメージがついたのは2018年ごろの話らしく、今では別の軽量イメージもある。（例: distroless） 以下のようなdistrolessを推す記事もあるので十分に検討

BusterとかStretchという名前が見慣れない方もいるかもしれませんが、これはLinuxディストリビューションとしてシェアの大きなDebianのコードネームです。 Debianバージョンが少し古いStretchの方がちょびっとサイズが小さかったりはしますが、まあ実用的にはサポートが長い方がいいですよね。slimを使ってGCCとかのコンパイラを自前でダウンロードしている記事とかもたまに見かける気がしますが、マルチステージビルドであれば、そんなにケチケチしなくていいのと、パッケージダウンロードは逐次処理なので遅く、処理系が入ったイメージのダウンロードの方が高速です。並列で処理されるし、一度イメージをダウンロードしてしまえば、なんどもビルドして試すときに効率が良いです。また、多くのケースでネイティブのライブラリも最初から入っており、ビルドでトラブルに遭遇することはかなり減るでしょう。 Py

こんにちは、 アプリケーションエンジニアとして働いてる、キムです。 今回は自分が作成、運営中のシステムのDockerイメージの最適化、イメージの軽量化のコツについていくつか方法を共有したいと思います。 確か、この方法以外により良い方法もあると思いますので、なにかあればコメントとかで残していただけると嬉しいです。 入る前に アプリケーションをDocker Containerで作って使う時、ちゃんと気にしないと作成されたDockerイメージの容量が考えたことより大きくてサーバーにデプロイするときや、共有が難しくなるかもしれません。 しかし、下記の流れをみてDockerイメージ容量に影響を与える部分をどうやって回避するのかを理解できれば、より軽量のイメージを作られると思います。 今日はその方法の中、自分が経験し適用してみたコツを共有しようと思います。 やってみましょう！ それでは比較のために何も

k8sとかとかすっごい人気ですよね。。。ただ、チームにk8sをといった前にDockerを知ってもらう必要があるなと感じ、いろいろなサイトを参考にしながら、布教教材を作成してみました。

概要 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

ただ自分の場合、変わらずexit with status 0になってしまった。 tty: trueはコンテナを起動し続けるオプションとのこと。 解決法 2 こちらも王道 docker-compose.yml に以下を追記する。 こちらは上手くいった。 しかし、起動時にシェルスクリプトを走らせるとexit with status 0に戻ってしまった。 ちなみにstdin_open: true は 標準入出力とエラー出力をコンテナに結びつける役割らしい。 docker run -it コンテナの名前 の -i 解決法 3 docker-compose.yml に以下を追記する。 こちらも上手くいった。 つまり、なにかコンテナ内でコマンドが走り続けていればいい？ docker-compose upを走らせるとAttaching to コンテナの名前となって起動状態が維持された。 まとめ 情報がバ

しかも何のエラーも出ないので困ってしまった。 ナンデ？？？ 原因 Dockerfile の ENTRYPOINT の指定が shell 形式になっていたことが原因。 shell 形式と exec 形式 Dockerfile の ENTRYPOINT や CMD には shell 形式 (shell form) と exec 形式 (exec form) の二種類があって、どちらでもビルドはできるが実行のされ方が異なる。1

以前この記事で書いたように Compose on Kubernetes をローカルで試した。 masayuki14.hatenablog.com サンプルのYamlで動かすことは出来たけど、自プロダクトのYamlは動かなかったのでまずはそれを解消することを目指した。また Kubernetes もそうが、Docker自体への理解も深めることも必要だった。 やったこと 本読み : 体系的に理解する Dockerfile にソースを含める ローカルレジストリの設置 今回のゴールは自プロダクトで使っている docker-compose.yml をローカルのCompose on Kubernetes で動作させること。 そのためにやったことは前述の3つ。 本読み : 体系的に理解する 購入した書籍はこちら。 Docker/Kubernetes 実践コンテナ開発入門 作者: 山田明憲出版社/メーカー:

はじめに Kubernetesがコンテナオーケストレーションツールのデファクトになったといわれて久しい1ですが、今年のAWS re:InventではAmazon EKS2の発表もあり、これからKubernetesに取り組もうという人もいるのではないかと思います。 かくいう私もその一人で、最近この辺りの技術に入門して色々と試していたので、今日はそのまとめを記します。 更新履歴 2020-05-09 Compose on Kubernetesについて追記 2017-12-12 初稿投稿 用語解説 Minikube Kubernetesクラスタをローカルマシン上で構築できるようにしてくれるものです。 Kubernetesクラスタを自前で一から構築するのは非常に大変そう(やったことはありません)なのですが、これを使うと簡単に試すことができます。 CIなどでも活用できそうです。 Kompose Do

【Mac環境】 komposeの代わりにCompose on Kubernetesを使ってdocker→kubernetes変換する方法Dockerkubernetesdocker-compose 記事の概要 最近業務でdocker環境をkubernetes環境に移行することなり、 試行錯誤したことの備忘録です。 docker-compose.yamlをkubernetesの各種yamlに変換するには、 メジャーな選択肢として、komposeを使う方法があるようですが、 私の環境では上手く動作するyamlが作れませんでした。（根気不足） そこでmacのDocker Desktopに付属のCompose on Kubernetesを 使ってみたところ、割りとスムーズにyaml変換ができました。 とりあえずkubenetes環境を動かせるyamlを手に入れられたことは、 作業の進捗とストレスの

アタッチとは： コンテナと接続している状態で、フォアグラウンドでコンテナが起動する。 デタッチとは： コンテナと切り離した状態で、バックグラウンドでコンテナが起動する。 オプション： オプション 省略形 説明 補足

テスト環境は全部入りでもいいが、ビルドしたものとテストに必要なものだけで済むならその方がいい(本番環境に近くなるので)

DjangoはPythonで書かれた、オープンソースウェブアプリケーションのフレームワークです。複雑なデータベースを扱うウェブサイトを開発する際に必要な労力を減らす為にデザインされました。

はじめに RailsアプリをDockerで環境を分けてbuildしようとしたときに詰まったことがありました。同じように詰まっている人の一助になればと思っています。 macOS Big Sur 11.6.6 rails 6.1.6 Docker 20.10.7 docker-compose 1.29.2 原因 開発・本番ともにDocker環境で構築 開発・本番でシステム構成が異なるのでDockerfile、docker-composeの中身が違う 開発から本番に移行する際に、Dockerfile、docker-composeの中身を本番に合うように変えた 以降、開発環境でDockerが使えなくなった 解決 開発環境用のファイルと本番環境用のファイルをそれぞれ用意する（自分的に一番簡単な方法だった） システム構成 開発環境（本番との違い: Nginxを使っていない、PostgreSQLのDoc

dev環境とprod環境で別のDockerfile使うってできるのかなdev環境ではホットリロードしたいからspring-boot:runで動かしてるけど，本番は実行可能jarにして動かしたい🐳 — ysek (@uuusu_) January 25, 2020 よくあるよね。ちょうど今書いているプロダクトがいろいろ使っているので説明してみる 基本１：環境別のファイルを使う 希望：Dockerfile.developmentとDockerfile.productionみたいなのを用意して使い分けたい docker build -f Dockerfile.development という具合にして指定することができる http://docs.docker.jp/engine/reference/commandline/build.html 基本２：start.shで分岐 希望：毎回ファイルを

#はじめに Dockerを開発環境で使うことが多くなってきてますね。 使い捨てできる環境は本当に便利なので、本番環境にも使いたいなーと思って、本番運用で注意すべきセキュリティ周りを調べてみました。 #基本的な考え方 基本的な考え方は以下になります。 コンテナ内部に入られるな 権限は最小限にせよ 監視を怠るな DockerといえどVPSやオンプレのセキュリティ設定と考え方は同じですね。 ここではDockerにまつわる話を書いていきます。 コンテナ内部に入られるな 信頼できるイメージを使う 多くの場合、ベースとなるピュアなOSイメージはDockerHub上のイメージを使いますが、元となるイメージがセキュアであるかどうかを確認して使うようにしましょう。 既知の脆弱性を含んでいる場合や、最悪の場合、悪意のあるスクリプトが仕込まれている場合があります。 既知の脆弱性が含まれているかどうかはDocke