先日 Docker Desktop が条件付きで有料になりましたね。Docker 社に金を払うのが間違いないとはわかりつつ、最近は Docker Desktop の代替となるものを色々と探していました。ちょっと前に見つけた lima という OSS が Docker 環境を構築するのになかなか良さげだったので、色々検証した記録をここに残します。 目次 TL;DR lima とは lima 上に Docker 環境を構築する lima のインストール 設定ファイルの用意 仮想マシンを構築 ホストマシンから lima 上の Docker daemon を利用する Docker CLI のインストール (Optional) Docker Compose v2 のインストール DOCKER_HOST 環境変数を設定する && ~/ssh/config を設定する（2021/10/22 追記） マウ

目次 はじめに 流れ 概要図 手順 Docker Desktopをアンインストールする。 HomebrewでLimaとDocker CLIをインストールする。 Limaを設定し起動する。 docker compose v2を導入する。 トラブルシューティング Host側(macOS)のdocker composeコマンドでエラーになる。 Lima-VM上でファイルを作成できない。 最後に 参考 はじめに Docker Desktopにおいて、M1 Mac上でx86_64イメージをpullしても、動作しない場合があります。そこで、以下の手順で、Docker Desktopの代わりにLima-VM上にDockerをインストールして動作するようにします。 流れ Docker Desktop for Macをアンインストールする。 HomebrewでLimaとDocker CLIをインストールする

業務やプライベートでのハンズオンを通して得た知見を元に、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

本文の内容は、2021年3月9日にÁlvaro Iradierが投稿したブログ(https://sysdig.com/blog/dockerfile-best-practices/)を元に日本語に翻訳・再構成した内容となっております。 Dockerfileのベストプラクティスのクイックセットをイメージビルドに適用することで、セキュリティ問題を防ぎ、コンテナ化されたアプリケーションを最適化する方法を学びます。 コンテナ化されたアプリケーションやマイクロサービスに精通している人なら、自分のサービスがマイクロサービスであることに気づいているかもしれません。しかし、脆弱性の検出、セキュリティ問題の調査、デプロイ後の報告や修正など、管理のオーバーヘッドがマクロな問題になっています。 このオーバーヘッドの多くは、セキュリティをシフトレフトし、開発ワークフローの中で可能な限り早く潜在的な問題に取り組むこ

初めて知ったときは感動したけど 自分の中で知ってて当然になってしまった小技をまとめました まだこの小技を知らない人に届いてくれるとうれしい Dockerfile RUNを1つにまとめる

buildspec.yml 内で docker login -u *** -p *** といった処理をしていなければ、それは匿名ユーザーで利用していることになります。 （ちなみに aws ecr get-login のログイン処理は ECR へのログインであり、Docker Hub のログインではありませんのでお間違えないように） 「匿名ユーザーで使ってるけど 6 時間あたり 100 pull も出来るならウチの環境では十分やなー」 と思ってスルーされた方も少なくないと思いますが、ちょっと待ってください。リンク先のブログで言及されているとおり、匿名ユーザーは IP アドレスに基づいて制限されます。 For anonymous (unauthenticated) users, pull rates are limited based on the individual IP address.

すごいタイミングですごい本が出たもんだ。 本日はKubernetes Advent Calendar 2020 その1 向けのエントリー。 本当はCF for k8sの記事を書くつもりだったのだけど、先週盛り上がりまくったDockershimのDeprecated話の後ですごーく良い本が出てきたので、これは紹介せねばということで急遽内容を変更。 jaco.udcp.info CF for k8sの話も途中まで書いちゃっているのでまた日を改めて公開する。 あの神資料が本になったよ ということで今日の話題はこちら。 イラストでわかるDockerとKubernetes Software Design plus 作者:徳永 航平発売日: 2020/12/05メディア: Kindle版 今では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. 影響範囲を知りたい場合

お詫びと訂正 おまけ２ の内容に関して誤りの情報を記載していたので、修正いたしました。(2020/6/6 22:55) またコメントで大変丁寧にご指摘&アドバイスをくださった@souchi00さん、ありがとうございます🙇‍♂️ 追記(コンテナについて)(2020/6/8 11:10) @inductorさんがコンテナに関するわかりやすい資料を紹介してくださいました！ https://www.slideshare.net/zembutsu/what-isdockerdoing コンテナについてより詳細を知りたい方は是非ご覧になってください ###　追追記(2020/6/8 12:30) 本記事で何点か誤った表記があったので、コメントで指摘くださった方々のアドバイスの元修正しております。(本文中でも修正しておりますが、コメント欄を見ていただければより詳細がわかると思います。) 以後このような

全国の nginx 職人のみなさま、こんにちは。野島(@nojima)です。 私の所属するYakumoプロジェクトでは、nginx を Go と Docker によってユニットテスト1しています。 手元で簡単に実行でき、ブランチへのpushのたびにCIでテストされるので、非常に便利です。 この記事では、このnginxのユニットテストについて紹介してみたいと思います。 背景 nginx は極めて柔軟なロードバランサであり、プロダクション環境ではその柔軟さを生かして多彩な役割を担っています。 我々の nginx は、ユーザーからのリクエストを AP サーバーに振り分け、アクセス制限を行い、リクエストをリダイレクトし、HTTPヘッダを付与したり削ったりしています。 しかし、nginx は便利な反面、その設定は極めて複雑になり、読解したり変更したりするのが難しくなっています。 そこで、nginx

はじめに 本記事では、コンテナに触ったことがない人に対して、コンテナ利用時のメリットを説明するための資料を公開します。 なお、ディップ社内ではPHPが利用している部署が多いので、PHPに関する記述が多いです。 注) この記事でことわりがない場合、｢コンテナ｣は｢Dockerコンテナ｣を指します。 コンテナ技術とコンテナイメージ コンテナ技術とは、プロセスを隔離して実行するための技術です。 コンテナイメージ(イメージ)とは、｢アプリケーションコードと依存関係を一つにまとめたファイル｣です。 コンテナイメージを元に実行された、隔離されたプロセスになったものをコンテナと呼ばれます。 VMとの違い VMは一つ一つにゲストOSが必要です。 コンテナは、プロセスを隔離してHostOS上で動作させることができます。 そのためオーバーヘッドや利用するリソースも少なく、高速に起動します。 https://w

上記コマンドで出力したとき最新のログにたどり着くまでに数分かかってしまうことが・・・。サクッと見たい・・・。 ログの削除で調べたが、うまく削除できずに困っていたところ、以下の情報を発見 つまり

運用管理が楽になり、クラウドとの親和性も高い――エンジニアならば避けては通れない「コンテナ」技術のメリットは、既に多くのエンジニアが肌で感じているものだろう。コンテナアプリケーションを動かすまでには、コンテナイメージを作成し、レジストリにアップロードし、そのイメージをデプロイ先にダウンロードし、コンテナを実行するというプロセスを踏む。コンテナアプリケーションの構成はDockerfileなどのテキストで表現できることもあり、構成管理は可読性も高い。 では、そこに“脅威”はないのだろうか？　コンテナ技術が普及期に入ったこともあり、昨今では“コンテナセキュリティ”に関しても注目が集まっている。しかしコンテナセキュリティが指すポイントについてはさまざまな意見があり、「いったいどこを守るべきなのか」「どこに脅威があるのか」がよく分からないというエンジニアも少なくないだろう。 そこで今回、トレンドマイ

TL; DR Docker/Kubernetes初心者の方と一緒に仕事をすることになったので、はじめの一歩として勉強会を開いたときに作成した以下の資料を公開しました。 speakerdeck.com 資料の目的 ZOZOテクノロジーズではたくさんのプロジェクトがあり、技術的にも古いものから新しいものまでいろいろなものが使われています。その多くは歴史的経緯や開発者たちのレベル感、今まで経験した技術などをベースに選定されることが多いです。 弊社 岡がCNDT2019にて発表した以下の資料や、ZOZOTOWNの作り直しの真っ赤な広告にもあるように、古い技術を使い続けてグロースを続けてきた結果、社内のプロジェクトのいくつかはスケーラビリティとして飽和に近い状態のものもあります。 ZOZOTOWNのCloud Native Journey from Toru Makabe www.slideshar

DockerやECR, ECS, Fargateなど、コンテナ周りのAWS知識を効率的にキャッチアップしたい人のためにAWSDockercontainerECSFargate 概要 私自身がコンテナや、コンテナ関連のAWSサービスについてはほぼ分からない状態だったのですが、そこからできる限り効率的に知識をキャッチアップしたくて学習したときの道のりです。 同じように困っていらっしゃる方のお役に立てばと思い、記事にしてみました。この道のりの通りに進んでいただければ、時間を無駄にすることなく、多少なりともスムーズに知識をキャッチアップできると思います。 主要な概念や全体像を理解するまでの道のり いきなり詳細に踏み込んでも、つまりいきなりFargateなどのAWSサービスを使っても、すぐに迷子になることは目に見えていましたので、まずは全体感や重要な概念、用語を理解しようと思いました。 そこで色々と

こんにちは。インフラエンジニアの永井(shnagai)です。 今回は、CodeBuildでのECSデプロイについて書いてみました。 普段、TravisCIを使ってメインサービスのECSのデプロイを行っているのですが、新規開発するにあたりCodeBuildを使ったECSのデプロイを組んでみたのでその内容をまとめています。 内容はざっくり下記4項目について書いてます。 CodeBuildのみで行うECSへのコンテナデプロイの構成図 他のCIサービスと比べた時のCodeBuildの良さ CodeBuildの設定でハマった点 デプロイフロー CodeBuildのみで行うECSへのコンテナデプロイの構成図 CodePipelineを使ったECSへのデプロイをする選択肢もあるのですが、これだと運用フローに大きく変更が入るので今回は、現在使っているecs-deploy を使ったECSデプロイを移植する形

はじめに 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本体から切り出された一部の機能で本番環境に投入され

docker 導入に関する記事を別で書くつもりだが、 今やっているプロジェクトで docker build で大ハマりしたので、 その解決方法をメモしておく。 概要 CentOS 7 Docker 1.6.2 上記環境だが、特に yum のリポジトリを更新することもなく、 下記を実行して Docker 1.6.2 をインストール。 yum install docker docker-selinux チームで管理している Dockerfile があるので、 それを落として色々インストールした後、 docker build して docker pull する予定だった。 「no such file or directory」のエラーでビルドできない Dockerfile は他の方が docker build 成功しているので、 俺の環境でもできるはずなのに build がどうやってもうまくいか

こんにちは、ぐるなびのインフラを担当している飯田です。 私の所属するグループでは、ぐるなび全体のサイトインフラの構築や運用を行っています。 私自身は、新卒で入社して今年で四年目となります。現在は、ぐるなび全体の仮想基盤やコンテナ基盤の運用、IaCなどを主に担当しています 。 今回は、我々が開発し提供している社内システムをコンテナ化し、そこでどういう技術に取り組んでいるかという話をしたいと思います。 インフラが提供する社内システムとは ぐるなびでは、サーバの払い出しやミドルウェアの設定変更などが発生する度にインフラへ依頼し、それに対してインフラが対応するフローをとっています。 このフローだと間接工数が増え、サービスの開発スピードが遅くなるなどの課題がありました。 そのため、開発効率やスピードの向上のため一部のオペレーションに対してGUI化やAPI化を実施し、社内システムとして提供しています。

概要 docker-composeを利用してADDやCOPYを行いたいときに気をつけることをメモします。 まず、docker-composeでホスト側のファイルをコンテナにマウントする際はDockerfileを利用します。 しかしながら、その際には以下の点に気を付けなければいけません。 DockerfileでCOPYかADDをするときにホスト側は絶対パスだとエラーになる Docker-composeのDockerfile内で親ディレクトリ参照したいとき これらを踏まえて、AddやCopyをする流れを説明しようと思います。 ここでの例は以下のディレクトリ構成で説明を行います。