AWSにおけるコンテナワークロード運用のデファクトスタンダードの地位を確立したECS。 デプロイ方法も進化を続け、CodeDeployとALBで連携したB/Gデプロイやカナリアリリースにも対応し、そのデプロイにおける柔軟性はEKSに勝るとも劣りません。 そんなECSですが、手段が豊富になったこともあり現…
AWSにおけるコンテナワークロード運用のデファクトスタンダードの地位を確立したECS。 デプロイ方法も進化を続け、CodeDeployとALBで連携したB/Gデプロイやカナリアリリースにも対応し、そのデプロイにおける柔軟性はEKSに勝るとも劣りません。 そんなECSですが、手段が豊富になったこともあり現…
はじめに やめろ、ではなく、やめたほうがいい。です。自分のユースケースに合ってるか今一度確認することを推奨します。基本的にはAlpineは避けたほうが良い、というのが2021年時点での私の認識です。 なんで？ libcに一般的な互換性が不足しているからです。Ruby、Python、Node.jsなどでNativeモジュールをバンドルしているアプリケーションの場合、パフォーマンスの劣化や互換性の問題にぶち当たる場合があります。 superuser.com あとは他のベースイメージの軽量化もそれなりに進んできていて、Alpineが定番軽量イメージと言う認識は2018年頃には消えつつあったかなという認識でいます。 どうすりゃええねん ※Debian Slimがあるやんってツッコミ結構もらったんですが、Slimは当たり前過ぎてもう紹介しなくていいかなっていう甘えで省略していました。よろしくおねがい
今話題のこれ。 kubernetes.io これに関しての日本語情報として、 @inductor が相当詳細に記事を書いてくれている。 blog.inductor.me blog.inductor.me にも関わらず、未だに完全に間違った解釈をしている人が多く観測される。記事をちゃんと読めば理解できるはずなのだけど、たぶんタイトルしか読んでいない。 タイトルしか読まないのであれば、あえて強めのタイトルにしておけば目にはつくかなと思い、改めて書いてみることとした。 Dockerは非推奨じゃないし、これからもバンバン使え まず @inductorが解説しているとおり、k8sを使っていない人には全く関係のない話なので、今まで通りDockerを使って良い。 が、もう一つ誤解を解いておきたいのが 自分の環境でDockerを使ってイメージ作成し、Kubernetesにデプロイしている人にも、今回の件は
追記: Kubernetes側での公式のアナウンスが2本出ているのでこちらも合わせてご覧ください。 kubernetes.io kubernetes.io Kubernetesコミュニティを眺めていたら、やたらめったら色んな人達が1.20 RCのリリースノート引っ張り出して「Dockerが非推奨になるからちゃんと対策を検討してね！！！」とアナウンスをしていて、挙げ句SIG Contributexではその対策に追われてバタバタしている自体を観測しました。 CNCF Ambassador Slackでもだいぶ燃え上がっていて、見かねて dev.to に記事を投稿したのでそれをかんたんに日本語にまとめてみようと思います。英語のほうはこちらをご覧ください。 dev.to 追記2. 影響範囲を知りたい場合はまずこちらをお読みください blog.inductor.me 追記2. 影響範囲を知りたい場合
Docker Hubは、Dockerコンテナのリポジトリとして最も有名かつ活発に使われているサービスの1つです。 おそらく多くのユーザーがDocker Hubに登録されたDockerコンテナのイメージを利用するなど、そのお世話になったことがあるでしょう。 そのDocker Hubにおけるコンテナイメージの保管について「Container Image Retention Policy」として規約が変更されたことが話題になっています。 Docker update ToS: Image retention limits imposed on free accounts | Hacker News Docker Hub の新しいコンテナ・イメージ保管ポリシー（参考訳） - Qiita これまでDocker Hubに保存されたコンテナイメージは期限なく保存され続けていましたが、今後はFreeプランの
二ヶ月ほど前に WordPressによる公式Dockerコンテナである wp-env がリリースされたが、現在は日本語ドキュメントの整備も進み、かなり成熟してきたようだ。 wp-envの特徴 さて、wp-envはDockerのnpmラッパーといった趣で、次のような .wp-env.json をリポジトリに用意しておくことで、開発環境がまるっと用意できる。 { "core": null, "plugins": [ "." ] } Dockerを利用したWordPress開発環境はいくつかあるが、利点は下記の通り。 公式でサポートされている。たとえば Docker がリリースしているWordPressイメージなどはファイルパーミッションなどがやや微妙だった。DockerとNode（v12以上）がインストールされていれば、環境を再現できる。追加ソフトウェアのインストールは不要（というより、npm
https://shuuu-mai.connpass.com/event/173794/
マイクロソフトは、Visual Studio Codeに対応したDocker拡張機能である「Docker for Visual Studio Code」がバージョン1.0となり正式版に到達したことを明らかにしました。 Docker for Visual Studio Codeを利用することで、Visual Studio Codeの画面からDockerコンテナイメージのビルド、コンテナ内アプリケーションのデバッグ、Dockerコンテナに対するスタート、ストップ、インスペクト、リムーブなどのアクションの実行が容易になります。 バージョン1.0ではPythonで書かれたコードに対するデバッグ機能を強化。DjangoとFlaskフレームワークにも対応します。DjangoやFlaskを利用する際のDockerファイルを作成するためのScaffoldにも対応。 複数のコンテナを選択し、まとめてスタート
Docker Desktop 2.2正式版が登場。WSL 2対応をテクニカルプレビューとして。ファイルシステムもSambaからgRPC FUSEへ WindowsおよびMacでDockerコンテナ環境を実現するDocker Desktopの最新版「Docker Desktop 2.2」正式版がリリースされました。 Now presenting #Docker Desktop release 2.2 https://t.co/qRDGy2B0fJ by @Nebuk89. Feat. WSL 2 as a tech preview, new file sharing implementation for #Windows & new integrated Desktop Dashboard. Thx to everyone who gave feedback! — Docker (@Dock
「Docker Desktop 2.2」では、これまでSambaに依存していたDocker上で動作するLinuxファイルシステムとWindowsファイルシステムの相互管理をgRPC FUSEに置き換えている。 gRPC FUSEへの置き換えによって、キャッシュを利用してページ読み込み時間を短縮するとともに、Linux inotifyイベントをサポートし、ソースコードが変更されたときに自動再コンパイル／リロードのトリガーが可能になったほか、Windows認証とは切り離して利用できるようになった。また、VPNの接続／切断にかかわらず利用可能で、管理者として実行されるコード量を削減している。 さらに、ローカルで実行中のコンテナと、Composeアプリケーションを管理できるインタラクティブなダッシュボードUIが採用された。WindowsとmacOSで共通のインターフェースを実現する、新たなデスクト
Docker社、WSL2に最適化した次期「Docker Desktop」でKuberntesサポートなど、さらなる機能強化を表明 Windows 10にLinuxカーネルを組み込むことで、フル互換のLinux環境を実現する新機能「WSL 2」（Windows Subsystem for Linux ver.2）は、現在のところ2020年春に予定されている次期Windows 10のメジャーバージョンアップで登場予定です。 参考：［速報］Windows上でフル互換のLinuxシステムコールを実現する「WSL 2」発表、Dockerも実行可能に。Microsoft Build 2019 Docker社はこれにあわせて、Windows 10でDockerコンテナの環境を構築するツール「Docker Desktop」のWSL 2対応をすすめています。 同社はそのWSL 2対応Docker Deskt
Docker for WindowsではCドライブを共有 エラーメッセージの通りなんですが、Docker for WindowsではCドライブのshareが必要になることがあります。 私はdocker-compose upした時に出ました。 多分ですがvolumes指定があったからでしょう。 コマンドラインオプションでも-vがあれば出ると思います。 >docker-compose up -d ... ERROR: for apache-php Cannot create container for service apache-php: C: drive is not shared. Please share it in Docker for Windows Settings. ERROR: Encountered errors while bringing up the project.
はじめに 前回の「DockerでRuby on Railsの開発をしよう」という記事で、Windows10HomeでもDockerを使えると言う話をしたが、自分では試していなかったので挑戦してみた。 もし、Windows10ProやMacを使えるならこの記事は参考にならないかもしれない。 概要 WindowsでDockerを使用したいときは、ProでDocker for Windowsを使うことが推奨されている。 しかし、今回はDocker for Windowsの対象になっていないHomeでDockerを動かしたい。 そこで、"Docker-Toolbox"を用いてDockerを動かしていく。 環境構築 さくっとできる。 Dokcer-Toolboxの導入 まずDocker Toolbox overviewからDocker-Toolboxをダウンロードする。 次に、ダウンロードしたものを
注意 2020年末にWindows Version 20H1 (2004)がリリースされました。Windows10 HomeもWSL2というLinuxを動かすことができるようになり、Windows 10 Proと同様のDockerが導入できるようになりました。 詳細は、下記、リンクをご参照ください。 目標 Windows10 HomeにDockerを導入するために必要な手順と最低限の知識をまとめようと思う。 あと、2018/06/16(日)にWindows10 Homeに Dockerを導入した手順となる。 対象者（ここ重要） Windows10 Homeの利用者に限ります。しかも64bitしかダメです。 Windows10 Professional、Windows Serverの人は対象にしません。 理由は、Windows10 Pro、Serverは、Windows自身が備える仮想環境（
はじめに SREチームの @minamijoyo です。 先日 CrowdWorks (crowdworks.jp) の本番環境のRailsアプリケーションを Docker (AWS ECS: Elastic Container Service) に移行しました。 CrowdWorksは2012年にサービスを開始し、2019年10月現在、ユーザ数は300万人、月間で数億円規模のお仕事がやりとりされる、国内最大級のクラウドソーシングプラットフォームにまで成長しました。 サービスの規模拡大に合わせて、ソースコードも数十万行規模に成長し、 決して小さくはない規模のRailsアプリケーションに成長しました。 CrowdWorksの開発環境にDockerが導入されたのはもうかれこれ3年半前の2016年の4月頃、2017年1月頃にはCrowdWorks本体から切り出された一部の機能で本番環境に投入され
みなさんコンテナを使うことの意味を自信もって答えられるでしょうか？ ここ1年ほどコンテナ関連の仕事をメインでやっているハマコーですが、いろんなお客様からこういったお声をいただくことが多くありました。 「それはコンテナ化する意味があるの？」 「こんなコンテナ運用は危ない？」 「ECSの設定とか実際めんどい。docker runじゃだめ？」 「EKSって使えんの？」 そういう声を聴く中で、自分なりの答えを模索していたわけですが、岡山での弊社イベントAWS最新技術の祭典Developers.IO 2019 at 岡山城へ登壇するにあたり、そのあたりのもやもやを自分なりに昇華したのが、本日の内容です。 「このアプリをコンテナ化する意味があるのか、わからない」 「コンテナ化することで余計めんどくさくなった」 「AWSのコンテナサービスの何を使ったら良いのかわからない」 という悩みを抱えている方には、
circleci 2.0 では、ジョブを実行する環境として、複数 docker image を指定できます。 https://circleci.com/docs/2.0/executor-types/#using-multiple-docker-images この環境では、以下が実現されています。 ビルドコマンドを実行するメインのコンテナにおいて、2つめ以降の image が expose するポートを、 localhost:${exposeされたポート番号} からアクセスできる docker で実行されているコンテナにおいて、このようなことはどうやったら可能なのだろう、とふと思いました。 というのも、例えば素朴に docker-compose で複数コンテナ実行を行った場合、他のコンテナは基本的にそのコンテナの名称がホストに設定されています。なので、どこのコンテナにアクセスするかは、その
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
