Read this article in English. はじめに 見つけやすく、インストールしやすいソフトウェアパッケージは、開発者にとって使いやすいです。React、Ruby on Rails、Airflow のような有名な OSS は良い事例です。しかし、社内の非公開のコードは、企業秘密として世間から隠されることが多いです。権限を持っている人のみ見ることができて、オープンソースのように npm gem や pip で簡単にインストールすることもできません。 その結果、社内のコードがうまく再利用されなくなる（あるいはできなくなる）ことがあります。各チームはそれぞれ独立したコードベースを持ち、他のチームにコードを共有したくても、満足がいく解決策を導き出すことが難しかったりします。戦略を立てないままでは、それぞれの独立したコードベースを充実させ続け「社内共通のライブラリー」が遠い夢のよう
Docker Compose入門 (4) ～ネットワークの活用とボリューム～ | さくらのナレッジ
これまでのDocker Compose入門は、Docker Compoesの紹介に始まり（第1回）、簡単なウェブサーバを起動する方法（第2回）、ネットワークの理解を深める方法（第3回）でした。今回は連載のまとめとして、ネットワークとボリュームの活用によって、1つのサーバもしくはPC上に複数のアプリケーション環境を動かす方法をみていきいましょう。 Docker Composeはプロジェクトごとにネットワークを持つ 前回はDockerのネットワークの扱いを学びました。Dockerコンテナを実行すると、そのコンテナ内のプロセスは、デフォルトで「bridge」という名称の仮想的な内部ネットワークを通して通信を行います。またホスト上のブリッジ（仮想的なネットワーク・スイッチ）を経由して、Dockerが作成する他の内部ネットワークや、ホスト側のインターフェースを通して、インターネットなどの外部ネットワ
2021/10/22追記：最新版は下記記事になります！こちらもご一読くださいませ。 tech-blog.abeja.asia どうも、Tech Blog編集長(自称)の緒方(@conta_)です。 よくエンジニアの方にご質問いただく ABEJAってよく聞くけど、実際どんなことやってるのかよくわからない という点をクリアにするために、事業内容と技術視点でのABEJAの取り組みを紹介したいと思います。 ABEJAに興味のある方や、未来の一緒に働くメンバーに読んでいただけると嬉しいです！ 割とAIコンサルの会社と思われているらしいので、ちゃんとプロダクト作ってますよ！ということを伝えていきたい ABEJAの事業紹介 ABEJAは2012年から約7年間、機械学習・ネットワークやIoTデバイスを活用したプロダクトの研究・開発・運用を行っています。 様々な産業・業種へ機械学習の適用・運用を培ってきたナ
概要 Docker コンテナの原則として「1コンテナ1プロセス」1というものがありますが、あえてこの原則を破りたいときがあるかもしれません。 公式: Run multiple services in a container 有志翻訳: コンテナー内での複数サービス起動 上記ドキュメントのラッパースクリプトを利用する方法には重大な問題があり、本番環境で使用するべきではありません。 (よりによって「本番環境でのアプリ運用」の項目にある) 公式ドキュメントに書かれているのに、死ぬというのはおかしいじゃないか それが罠だという証拠 ちなみに supervisord を利用する方法は問題ありません。 また、コンテナ向けに最適化された s6-overlay2 を利用する方法もあります。 ラッパースクリプトの問題点 プロセスの graceful shutdown が実行されない(プロセスに SIGKIL
Docker DesktopとAmazon ECS（Elastic Container Service）が連係可能に。DockerとAWSが協業
Docker DesktopとAmazon ECS（Elastic Container Service）が連係可能に。DockerとAWSが協業 WindowsやMacでDocker環境を利用できる「Docker Desktop」と、Amazon Web Services（AWS）のコンテナ環境であるAmazon ECS（Elastic Container Service）との連係が、DockerとAWSから発表されました（Dockerの発表、AWSの発表）。 From Docker Straight to AWS? Why, yes you can. Read about our collaboration with @AWSCloud https://t.co/Hy1Nvq3m0r #AWS #Docker #Containers #Cloud pic.twitter.com/92gL
本稿は、Christffer Noring さん (@chris_noring) の Learn Docker, from the beginning を翻訳し、分かりやすいように少しだけ追記、サンプルコードの実行上の補足等を行ったものです。Docker について教科書的な使い方を実際に実行して確認しつつ、Docker Composeを使ったオーケストレーションの基礎までを導いてくれます。今、Docker で注目されるのは、コンテナ同士が連携する、オーケストレーションです。本稿ではオーケストレーションの最も基礎となる Dokcer Compose までですが、オーケストレーションを活用するための基礎的部分の考え方を実地を以ってしっかりと理解できます。その意味で、原題は「from the beginning」ですが、初心者向けと言うよりも、今現在進行形の技術トレンドをキャッチアップするための
Docker DesktopがWebAssemblyランタイムを統合。コンテナと同様にWebAssemblyイメージを実行可能に
Docker DesktopがWebAssemblyランタイムを統合。コンテナと同様にWebAssemblyイメージを実行可能に Docker Desktopを提供するDocker社は、Docker DesktopにWebAssemblyランタイムを統合することによる、Docker DesktopのWebAssembly対応版のテクニカルプレビューを発表しました。 またDocker社はこれに合わせて、WebAssemblyをあらゆるプラットフォームでセキュアに実行できるようにするための仕様策定と実装を進めている団体「Bytecode Alliance」への加盟も発表しました。 DockerにWASMランタイムのWasmEdgeを統合 下記の図がDocker DesktopにWebAssemblyを統合した仕組みを示しています。 左側と中央は通常のDockerコンテナを利用する場合の仕組みで
はてなブログをECSに移行してリリース頻度も改善した話 - Hatena Developer Blog
この記事ははてなエンジニア Advent Calendar 2022の26日目のエントリです。 こんにちは id:cohalz です。はてなブログでは2022年7月にインフラをAmazon EC2からAWS ECS(AWS Fargate)に移行するプロジェクトが完了しました。 プロジェクトは2021年9月から始まったので約10ヶ月間という大きなプロジェクトでした。 プロジェクト完了までに行ってきたことのうち、特に面白かったところなどをこの記事で実施した順に振り返ってみます。 はてなブログのインフラのこれまで アプリケーションを動かせるようにする ALBを追加する 検証環境を用意だけしておく プロキシの設定埋め込み 証明書の配信 アクセスログを配送できるようにする アクセスログの形式を新しくする EC2でもFirehoseを経由するように タイムゾーンをUTCに統一 FirehoseのLa
Pipenv と Docker を使った開発環境のベストプラクティス - kawasin73のブログ
イテレーションの速さがあなたの生産性を左右する。どうも、かわしんです。生産性の高いプログラマって１つ１つの試行が素早い（自動化しているかツールを使っている）ためにものすごいスピードで開発できていると思うんですよね。 さて、最近 Python で開発をしているのですが、世の中の Docker と Pipenv の開発環境を調べてもろくなものがなかったので、自分でテンプレートを作りました。いわゆる「俺の考える最強の Pipenv + Docker 開発環境」というやつです。 リポジトリはこちらになります。 github.com 特徴としては、以下の2つが大きいです。 pipenv install をコンテナ起動時に行うため、docker イメージを作り直す必要がない pipenv shell 相当の仮想環境のアクティベートを自動で行う なぜ Docker + Pipenv なのか Docker
仕事でPythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編 | フューチャー技術ブログ
BusterとかStretchという名前が見慣れない方もいるかもしれませんが、これはLinuxディストリビューションとしてシェアの大きなDebianのコードネームです。 Debianバージョンが少し古いStretchの方がちょびっとサイズが小さかったりはしますが、まあ実用的にはサポートが長い方がいいですよね。slimを使ってGCCとかのコンパイラを自前でダウンロードしている記事とかもたまに見かける気がしますが、マルチステージビルドであれば、そんなにケチケチしなくていいのと、パッケージダウンロードは逐次処理なので遅く、処理系が入ったイメージのダウンロードの方が高速です。並列で処理されるし、一度イメージをダウンロードしてしまえば、なんどもビルドして試すときに効率が良いです。また、多くのケースでネイティブのライブラリも最初から入っており、ビルドでトラブルに遭遇することはかなり減るでしょう。 Py
Docker イメージを利用したローカル開発環境向けメールサーバ構築のすゝめ｜TechRacho by BPS株式会社
ebi です。 弊社では Rails だけでなく、 WordPress 等を利用した PHP 環境、WordPress 等のフレームワークを利用するまでもなく、素の PHP で構成されるページを作成、保守することもあります。 往々にして LP だったり、コーポレートサイトやサービスサイトが中心で、サイト上からのメールの送信を伴う問い合わせフォームがセットとなっていることが多いです。 Rails だとメール送信は Action Mailer を利用して、メール受信は letter_opener 等を利用すればすぐにそれっぽい画面で確認できて便利だな、と思っていたのですが、そこそこ前から Rails 以外のプロジェクトでも、 Docker を利用して letter_opener 相当の環境を手元に用意しているのが便利なので今回はそれを紹介します。 これまでの話 ところで、そもそもこれまではどう
こんにちは、CX事業本部の夏目です。 Golangは最近人気の言語で手を出そうとは思っていたのですが、環境構築がいまいちよくわからなくてできてませんでした。 (goenvを使ってGolangをインストールするときGOPATHはどうしたらいいとかよくわからなかったのです) 今日はVisualCodeとDockerを使って、Golangの開発環境をMac上に作成しようと思います。 環境構築 事前準備 VSCodeとDockerをインストールします。 Visual Studio Code - Code Editing. Redefined Docker Desktop for Mac and Windows | Docker Version 2.0以上 拡張機能のインストール VSCodeのExtension "Remote-Containers"を使用して開発環境を作ろうと思います。 Micr
パイプライン処理とは GUIは非常に直感的です。はじめて使うアプリであっても、なんとなくそれなりに動かせてしまうという点で、優れたインターフェイスと言えます。しかし効率を突き詰めると、軍配が上がるのはGUIよりもCLIでしょう。本連載の読者であれば、UnixライクなOSのCLIが持つパワーについては当然ご存知かと思います。 とはいえ、古典的なUnixコマンドの多くは、単体ではそれほど強力なものではありません。というのも、ひとつひとつのコマンドはシンプルに、特定の用途においてのみ上手く動作するよう設計されていることがほとんどだからです。こうしたコマンド群に無限のシナジーを与えるのが「パイプライン処理」です。標準入出力を通じて複数のコマンドを直列に繋げることで、複雑な処理をインスタントに組み立てることができるパイプラインは、まさにUnix哲学の体現であり、CLIの真髄はここにあると言ってもよい
MacからWindowsへの開発機移行から2年
開発機をMacからWindowsに移行して2年ほど経った時点での振り返り。 年表 2009年07月 MacBook Pro 1を購入、プログラミング開始 2014年07月 MacBook Pro 2を購入 2016年12月 Windows機1を入手、PCゲーム開始 2017年07月 MacBook Pro 3を購入 2018年06月 Windows機2を購入 2020年09月 MacからWindowsへ開発機を移行 2021年01月 Windows機3を購入 2022年10月 現在 過去記事 開発機を移行してすぐの頃の感想は、次の記事に書いた。 Windowsで開発 Windowsへの回帰 自作PC2021 デスクトップPCを譲渡 Macからの移行という観点だと、次の記事も幾らか関連があるかもしれない。 AirPodsをWindowsで使う Windows10でMagic Trackpad
Red Hat、ローカルマシンにコンテナとKubernetes環境などを構築する「Podman Desktop 1.0」正式リリース
Red Hat、ローカルマシンにコンテナとKubernetes環境などを構築する「Podman Desktop 1.0」正式リリース Red Hatは、ローカルマシンにLinuxのコンテナとKubernetes環境を手軽に構築できる「Podman Desktop 1.0」を正式リリースしました。 Windows、macOS、Linuxに対応し、デスクトップアプリケーションからコンテナエンジンのPodman、Docker、OpenShift Localなどを簡単にインストールでき、最新の状態に保つことができます。 コンテナの実行やKubernetesの操作など Podman Desktopの主な機能は以下の通り。 コンテナとポッド関連 コンテナとポッドのビルド、ラン、マネージ、デバッグ Kubernetes上もしくはKubernetesなしでのポッドの実行 内蔵のターミナル機能でコンテナへの
GitHub Codespaces 雑感
GitHub Codespacesをちょっと試した。 初期導入時にハマりどころも多いけど、真面目に設定しておけば、普通にCodespacesの環境だけで開発することは十分できそうだなと感じた。リポジトリ単位で環境を用意するのが基本で、多くのリポジトリに対して毎日のようにレビューをしたりPull Requestを出したり、みたいな開発フローには綺麗にはまらないと思うけど、普通に仕事で単一のリポジトリに対してだけ作業する用途であれば上手くはまると思う。Zoomで会議しながら重い処理を実行していても影響が無いのは良かった。Zoomで会議しながら重い処理を回すべきではないという意見もある。 Codespacesの利用の流れ Codepsacesを利用するときの流れについて。まず、予め .devcontainer/devcontainer.json を配置したリポジトリを用意しておく。Codespa
Docker ❤️ WSL 2 - The Future of Docker Desktop for Windows | Docker
One of Docker’s goals has always been to provide the best experience working with containers from a Desktop environment, with an experience as close to native as possible whether you are working on Windows, Mac or Linux. We spend a lot of time working with the software stacks provided by Microsoft and Apple to achieve this. As part of this work, we have been closely monitoring Windows Subsystem fo
GitHubによるDockerコンテナレジストリ「GitHub Packages Container registry」が正式サービスに
GitHubによるDockerコンテナレジストリ「GitHub Packages Container registry」が正式サービスに GitHubは、Dockerイメージの共有や公開ができるリポジトリサービス「GitHub Packages Container registry」が正式サービスとなったことを発表しました。 Container registry for GitHub Packages is now generally available! Check out how it can improve your development experience.https://t.co/qCe9DteR6d — GitHub (@github) June 21, 2021 GitHub Container Registryは、GitHubでソフトウェアパッケージを扱う機能である「G
Dockerfileを作る時、最初は以下の方法でやってました。 Dockerfile書く ビルドする（動かしたいアプリ含め） 起動してみる 動かなかったらDockerfile修正する またビルドして試す こんな感じでしたが、これは非常に効率が悪いです。修正して検証を行う度にビルドが発生してしまい、待ちが発生してしまいます。 どうするか？ ベースイメージにアタッチ 動かしたいアプリの実行に必要なコマンドを入れて、成功したらコマンドをメモっていく アプリが動くまで「コマンド実行→成功したらメモ」を繰り返す アプリが動いたらメモったコマンドでDockerfileを作る つまり、いきなりDockerfileを作るのではなく、ベースイメージに入ってコマンドを実行して動作確認をしながらDockerfileに記述する内容を固めていき、最後に1回だけビルドします。 なぜ？ Dockerfileに記述するの
リモートワークが一般的になり、一方でさまざまな課題が生じてきています。特にコミュニケーションの課題などは多くの人に関係するため大きな関心を集め、急速にさまざまなソリューションが出てきています。一方で開発業務に目を向けると、少しずつ進みつつあるものの、デファクトと言えるほどのものもなく、情報もあまり共有されていないように思います。そこで、筆者がいろいろと試行錯誤をしながら行った施策について紹介したいと思います。 はじめに 今の開発現場ではDockerなどを使った仮想化コンテナを使うことが一般的になっています。そのため、ソースリポジトリ（Gitなど）と仮想化コンテナを使えば、各開発者が開発環境を構築し、業務を進められます。つまり、オフィスのPCを自宅に持ち帰るか、もしくは自宅のPC上で開発環境を構築してしまえばそれで問題は解決するのです。 しかし、どちらの方法もセキュリティや情報管理の観点から
Docker Buildにおけるリードタイム短縮のための3つの改善ポイント | PLAID engineer blog
Dockerfile効率化のベストプラクティスを、リードタイム(CI/CDの実行時間)を短縮し開発生産性を向上させる為に行うべき事という観点でまとめました。 1.Docker Daemonへの転送ファイル削減 2.Docker Imageのサイズ削減 3.cacheの有効活用
CTOの川口 (id:dmnlk) です。 プロダクト開発組織を運営していく中で地味ながら無視できないものとして、「支給PCの選定」というものがあります。 PCスペックによって大きく作業効率が変わるので、なるべくで希望通りのものを支給していくというのが基本方針ではありますが同時に社内資産としての価値やチームでの伝達効率といった点は重要です。 それらを考えるなかで、1年ほど前に発売されたAppleのM1チップ搭載のMacについて解禁するまでの過程を紹介します。 この文章はもともと社内向けに公開予定でしたが、使用PCの選定基準を最も知りたいのはこれから入社される方ということに気づいたため入社前にアクセスしやすい文書として公開ブログとすることにしました。 今までのエンジニア/デザイナー向け支給PCの基準について BASEでのエンジニア/デザイナーに支給しているPCは現在下記の基準になっています。
そこそこの規模があるプロジェクトで実行すべきタスクを定義するとき、初手として Makefile を使いがち。 Pros make は事実上どんな環境にもあることを期待してよい シェルで実行されるコマンドをそのまま書ける タスクの依存関係が明示できる Cons make では positional arguments が使えない 少し複雑なことをしようとすると Makefile 専用の文法を覚える必要がある 現代では、ファイルベースのタスクの依存関係は make が発明されたころほどは必要ではない Docker とか Go とか Webpack がよしなにしてくれることが多い 例: docker compose のラッパー ちょっとしたコマンドのラッパーを書きたいことがある。Makefile を書きはじめたらすべてのエントリポイントを make にしたい。ということで、以下のような Make
Mutagen compose Mutagen composeは、Mutagenというローカル環境とリモート環境のディレクトリを高速に同期させることができるオープンソースの開発ツールをDocker composeと統合させたツール。 つまり、Docker環境でホスト側とコンテナー側のファイル同期を高速で行うのに特化したサードパーティーのツール。 事前準備 mutagen-composeのインストール
OSC 2020 Online/Fukuokaの資料です。
Amazon ECSで動かすRailsアプリのDockerfileとGitHub Actionsのビルド設定 - メドピア開発者ブログ
CTO室SREの@sinsokuです。 Dockerイメージのビルドを高速化するため、試行錯誤して分かった知見などをまとめて紹介します。 AWSのインフラ構成 assetsもECSから配信し、CloudFrontで /assets と /packs をキャッシュする構成になっています。 Rails on ECS デプロイ時にassetsが404になる問題 以前の記事に詳細が書かれているため、ここでは問題の紹介だけしておきます。 Rails等のassetsファイルをハッシュ付きで生成し配信するWebアプリケーションの場合、ローリングアップデートを行うと、アップデート時に404エラーが確立で発生してしまいます。 引用: メドピアのECSデプロイ方法の変遷 Dockerfile 実際のDockerfileには業務上のコード、歴史的な残骸などが含まれていたので、綺麗なDockerfileを用意しま
もろもろの事情でDocker Desktopを使いたくなくなったため、Docker Desktop for Windows無しに、似たようなDocker環境をWindowsに構築する手順を確認しました。 (2021-09-05追記) 私はWSL2をDocker以外の目的で使用していないので気にしませんが、他の目的にも使っているという方は 「(おまけ) Docker用のディストリビューションを分ける」 を先に参照したほうが良いかもしれません。 (2022-01-29追記) Visual Studio Code (VSCode) に、WSL環境内の docker コマンドを直接使用できるオプションが追加されました。この機能を有効にすると、VSCodeからコンテナを使用するために一旦WSLに接続したり、Windows側にDocker CLIをインストールしたり、というステップが不要になります。詳
Raspberry PiでAWS互換のコンテナ環境を作れるAmazon ECS Anywhere。AWSがコンテナとKubernetesでハイブリッドクラウド／マルチクラウド対応へ大きく踏み出す
AWSの競合であるGoogle CloudやMicrosoft Azureは、すでにコンテナとKubernetesをベースとしたハイブリッドクラウド／マルチクラウドのソリューションであるAnthosとAzure Arcを展開しています。 AnthosもAzure Arcも、Kubernetesによってクラウド基盤やオンプレミスを抽象化したうえでコンテナのポータビリティを用いることで、自社クラウドのアプリケーションをオンプレミスでも他社のクラウドでも実行可能にすることを基本的な仕組みとしています。 「Amazon ECS Anywhere」と「Amazon EKS Anywhere」も、これらと似たソリューションを提供するものといえます。 コンテナのポータビリティとKubernetesのインフラ抽象化の機能を活用することで、AWS上のコンテナアプリケーションが簡単にオンプレミスや他社クラウド
[旧版]クジラに乗ったRuby: Evil Martians流Docker+Ruby/Rails開発環境構築（翻訳）｜TechRacho by BPS株式会社
まえがき 本記事は、私がRailsConf 2019で話した「Terraforming legacy Rails applications」↑の、いわばB面に相当します。この記事を読んで、皆さんがアプリケーション開発をDockerに乗り換えるとまでは考えていません（皆さんが以下の動画で若干言及しているのをご覧になっていたとしても）。本記事の狙いは、私が現在のRailsプロジェクトで用いている設定を皆さんと共有することです。それらのRailsプロジェクトは、Evil Martiansのproduction development環境で生まれたものです。どうぞご自由にお使いください。 原文免責事項: 英語版記事は最新の推奨事項に合わせて更新を繰り返しています。詳しくは記事末尾のChangelogをご覧ください（参考: 原文Changelog）。 私がdevelopment環境でDockerを使
![[旧版]クジラに乗ったRuby: Evil Martians流Docker+Ruby/Rails開発環境構築（翻訳）｜TechRacho by BPS株式会社](https://cdn-ak-scissors.b.st-hatena.com/image/square/21560bbf17dc149933029263d3a38154359b86f5/height=288;version=1;width=512/https%3A%2F%2Ftechracho.bpsinc.jp%2Fwp-content%2Fuploads%2F2019%2F09%2Fdockerizing_ruby_rails_development_eyecatch2-min.png)
JJUG CCC 2023 Fall
はじめにこんにちは、Finatext で保険事業のプロダクト開発をしている @toshipon です。今回は以前の Fin-JAWS のイベントで少し紹介させていただいた、我々の現場で取り組んでいる、大規模API開発における Swagger を用いたAPI仕様のドキュメント運用方法について紹介いたします。 概要我々の現場では、API ベースのWeb Application を開発する際に、Swagger を用いて API 設計をしたり、BFFサーバー開発者やフロントエンド開発者とのコミュニケーション手段として活用しています。 ただし、Web Application の規模が大きくなってくると、Swagger の 定義ファイルは肥大化してしまい、メンテナンスが困難になってきます。 今回は、Web Application の規模が大きくなっても耐えうる Swagger 定義ファイルの運用方法を
インフラ基盤技術のセキュリティとこれから
InfraStudy #6 https://forkwell.connpass.com/event/187694/ での発表資料 ターミナルの画像は GIF なのでスライド内のリンクか https://gist.github.com/mrtc0/16f169e679674e43dfbb33ae5b0c4d5e を参照してください。動画は https://www.youtube.com/watch?v=X8HvH3dF6ZM です。
監視・通知の仕組みの全体像また、弊社では Terraform を用いて IaC ( Infrastructure as Code ) を実現して、各AWSアカウント環境の状態をコードで一元管理していますが、 Datadog の監視項目も Provider が用意されているため、Terraform で管理をすることが可能です。現状はすべての Datadog の監視項目がコード化されているわけではないですが、こちらは随時対応を行っていきたいと思っています。 外形監視外形監視は、WebサイトやAPIエンドポイントが正常に動作していることを、定期的に特定のURLに対して問い合わせをして、期待されたステータスコードや要素を返すことを監視することを目的とします。 弊社では Datadog の Synthetic Monitoring という機能を利用して監視を行っていますが、この機能の特徴としては W
Dockerコンテナをサーバレス化する「Google Cloud Run」で、非同期処理やバックグラウンドタスクなどが実行可能に
Googleは、Dockerコンテナをサーバレスで実行するサービス「Cloud Run」の新機能として、非同期処理などを可能にする「CPU allocation on Cloud Run」機能をプレビューとして発表しました。 非同期処理などが難しかったCloud Run サーバレスコンピューティングでは一般に、何らかのイベントやリクエストをトリガーにインスタンスが起動し、処理が終わるとインスタンスが終了します。 Google CloudのCloud Runではこうした処理をDockerコンテナで実現するサービスです。HTTPやgRPCなどによるリクエストによってあらかじめ用意されていたDockerコンテナが起動し、レスポンスを返したところでDockerコンテナが終了してCPUの割り当てが解放されるようになっています。 そのため、Cloud Runでは処理を非同期にしてレスポンスを先に返し、
CircleCIが無料枠を大幅拡大。1カ月あたり6000分のビルド時間、ユーザー数無制限、最大30件までのジョブ同時実行など
CircleCIが無料枠を大幅拡大。1カ月あたり6000分のビルド時間、ユーザー数無制限、最大30件までのジョブ同時実行など CI/CD機能をクラウドサービスとして提供するCircleCIが、無料枠を大幅に拡大したことを発表しました。 At CircleCI our mission is to help teams deliver software faster and better. We’re so confident that you’ll be successful with CircleCI that we’ve added more features and more resource classes than ever before to our Free plan. https://t.co/oEuEREcTkv — CircleCI (@CircleCI) January
AWSがDocker Hubの代替サービスを発表予告。パブリックにコンテナイメージを公開可能で50GBまで無料、AWSからなら何度でもプルし放題に
Amazon Web Services（AWS）は、数週間以内にDockerコンテナイメージをパブリックに公開できる新たなコンテナレジストリサービスを発表すると明らかにしました。 Docker Hubの無料プランはプル回数を制限へ 現在、Dockerコンテナイメージのパブリックなレジストリとして事実上の標準となっているのは、Docker社が運営するDocker Hubでしょう。 Docker Hubは誰でもコンテナイメージを公開でき、また、誰でも公開されたイメージを取得（プル）できます。しかしDocker社は今年夏の時点で15ペタバイトにまで膨れ上がったDocker Hubのサービスの無料プランをこのまま続けていくのは難しいと判断し、無料プランに対しては以下の制限を加えることを発表しました。 6カ月以上使われなかったコンテナイメージは削除する アノニマスユーザーからのプルは6時間で100回
Docker Desktopが一定条件で有償化*1されるので、脱Docker Desktopしてみた。 意外とそんなにハマることもなく環境構築に成功して、Docker Desktopを使っていた時代とほぼ変わらない開発体験が得られました。 Limaを選んだ理由 lima コマンドを打つだけでデフォルトのVM(Ubuntu)のシェルに入れる(もしくはlimaの後ろに付加した文字列がそのままコマンドになる) 標準設定でホストとネットワークを共有する(dockerでportをexportしたらlocalhost:1234でアクセスできる) --net=host が使える 標準設定でMacのホームディレクトリがVMにマウントされてる(嫌だったら設定変えられる, sshfsでマウントされてるだけ) 環境 M1 Mac Book Pro Intelでもいけるはず Lima側の構築 これがDocker
`COPY --chmod` reduced the size of my container image by 35%
$ podman history vamc19/nomad:latest ID CREATED CREATED BY SIZE COMMENT ... <missing> 36 minutes ago /bin/sh -c apt-get update && apt-get insta... 94.4 MB 374515aec770 36 minutes ago /bin/sh -c # (nop) COPY file:6dbfa42743cc65... 87.7 MB 22cd380ad224 36 minutes ago /bin/sh -c # (nop) LABEL maintainer="Vamsi"... 0 B FROM docker.io/library/ubuntu:21.10 ... The layer created by COPY is 87.7MB, which
「Rancher Desktop 1.0」正式リリース。Win/M1 Mac/Intel MacにコンテナとKuberntes環境を簡単に構築、設定できるElectronベースのアプリ
「Rancher Desktop 1.0」正式リリース。Win/M1 Mac/Intel MacにコンテナとKuberntes環境を簡単に構築、設定できるElectronベースのアプリ SUSEは、インストールして起動するだけでWindows やMac上に簡単にDockerコンテナとKubernetes環境が導入される「Rancher Desktop 1.0」を正式リリースしたと発表しました。 SUSEがRancher Labsを買収して最初の大きなプロダクトとなります。Windows、M1 Mac、Intel Mac、Linuxに対応します。 At SUSE, we want to make the experience of working with #Kubernetes on your desktop easier and simpler, which is why we are
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
社内コードを公開せずに内部で共有する方法 - Qiita
ABEJAの技術スタックを公開します (2019年11月版) - ABEJA Tech Blog
1コンテナ複数プロセスはやめておいた方が良い話 - Qiita
超基礎からの 速習 Docker (1) - Qiita
VSCodeとDockerでMacにGolangの開発環境を作成する | DevelopersIO
第723回 複雑なコマンドパイプラインを簡単に組み立てる方法 | gihyo.jp
https://twitter.com/_inductor_/status/1607160892973789184
Dockerfileの作り方を考え直したらすごく効率が上がった
DockerとSSHでセキュリティと手軽さを両立したリモート開発環境を構築する
エンジニア/デザイナー向け貸与PCにM1 チップMacを解禁するまで - BASEプロダクトチームブログ
Makefileの代わりにnpm scripts+zxを使う - 詩と創作・思索のひろば
遅いDocker for macを「Mutagen compose」で爆速にする（M1対応） - Qiita
これから始める人のためのKubernetes&CloudNative入門
Docker Desktopに依存しない、WindowsでのDocker環境 - Qiita
コンテナ環境でのJavaトラブルシューティング
swagger-merger を用いた大規模API開発における Swagger 運用
次世代デジタル保険を支える監視・通知の技術
M1 MacでLima + Dockerの環境構築 - くろの雑記帳