モバイルアプリサービス部の五十嵐です。 先日、あるRailsアプリケーションの開発環境を同僚のマシンに作成しようとしたところ、gemのインストールに1日かかってしまいました。環境構築は手順化されていたのですが、トラブったのは主にNative Moduleを利用する libv8 、 therubyracer 、 rmagick などのおなじみの面々です。手順を作った時は、これらのgemのインストールに必要なライブラリを brew install で最新バージョンをインストールするだけでよかったのですが、時が経ちライブラリの最新バージョンが更新されていたことが主な原因でした。この状況はいかんな〜と思い、Railsアプリケーションの開発環境もDockerにすることにしました。 本記事では、Railsアプリケーションの開発環境をDockerにするときに検討したことや問題点などを書いています。なお、
Entrykit のすすめ - Qiita
はじめに あなたは Docker イメージを作る際に start.sh や startup.sh というファイルを作った経験はないだろうか。「Dockerfile の CMD だと 1 コマンドしか書けないから、シェルスクリプトで頑張る」というやつだ。例えば、環境変数を受け取って設定ファイルを動的に作ったり、メインプロセス起動前に何かしら初期化処理をするなど。そんなあなたに Entrykit というツールを紹介しよう。 Entrykit とは Entrykit は一言でいうと、コンテナ内のプロセス起動時に便利な軽量 init システムだ。Docker の起動コマンドに Entrykit を使うと、起動時にテンプレートファイルを元に設定ファイルをレンダリングしてくれたり、メインプロセスの前にコマンドを実行できたりする。 公式サイト - https://github.com/progrium/
Node.jsコンテナイメージを極限まで軽量化! サイズを1/10以下に｜SHIFT Group 技術ブログ
はじめにSHIFT DAAE の shinagawa です。表題の通りNode.jsで作成したコンテナのイメージサイズの軽量化に挑戦しました。 背景近年の多様化・高速化するビジネスに対応するITシステムの構築を実現する「クラウドネイティブ」の構成要素の一つとして 「コンテナ」という仮想化技術が存在し、当部門でも活用を進めております。 このコンテナイメージを作成するにはアプリケーションコードやライブラリ・モジュールなどの依存物、ランタイム等を1つのイメージとして組み立てて作成しますが、 この構成要素が増えるとイメージサイズが肥大化し保管時のストレージのコストの増加やイメージの転送、環境への展開に時間がかかることになります。 従ってイメージのサイズを削減することは、これらの点を改善することにつながります。 ここではネット上で紹介されている、あらゆる打ち手を組み合わせてコンテナイメージの軽量化に
機械学習プロジェクトでは python を始めとした言語 + それに付随したライブラリを使います。 僕も python 触りたての頃はローカルマシン上にひとつ python 環境を作り、必要なライブラリをインストールして使っていました。環境の分離ということはあまり意識しておらず、やったとしてもプロジェクトごとに anaconda や pyenv, venv などで個別環境を作って切り分けるレベルでした。 しかし上記の方法だと困ったことが起ることがあります。例えば… global な環境が壊れてしまってすべて壊れる。 これは各環境が global な環境に依存しているために起こります。 python 以外の変更で環境は突如として壊れます。例えば brew install hoge したら Mecab が使えなくなっちゃったとかはあるあるだと思います >_< linux / Mac / Win
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
今年も残すところあと10日となりました。 Docker Advent Calendar 2015 22日目 山中です。 簡単に自己紹介 Advent Calendar 経由でお越しになった方もいらっしゃるかと思いますので簡単に自己紹介させて頂きます。 名前: 山中 悠 (@yuurelx) 経歴: -2009 バイトで検索エンジン開発＆自宅データセンター 2009-2014 株式会社HDE (Programmer/SE/PM/Infra. Engineer) 2015 株式会社ペロリ (DevOps Engineer) 2016- INGoT合同会社 (CTO), Reactive Inc. (Core Engineer) 登壇歴: Docker Meetup Tokyo #5 SCRIPTY #4 Sensu deep talks #1,#2 Fashion Tech meetu
はじめに 本記事は複雑な構成をとるrailsアプリケーションをdockerで動作させる場合についてまとめています。 これまでにrailsを動作させるコンテナのDockerfileをどう記述するのが良いかという観点と、railsアプリケーションのプレビュー環境をdockerで構築出来るかという検証の二つの記事を公開していました。 railsをdockerで動かしたい場合の構成はどうするべきか - Qiita Docker(pool)を用いたプレビュー環境を検証する(railsアプリ開発チームの活用例) - Qiita 先に公開した二つの記事では、railsアプリケーションを単独のコンテナで動作させる場合について言及しています。 しかしアプリケーションの規模が大きくなるとrails単体だけでは無く、キャッシュにmemcachedやredis, 検索にsolrにelasticsearch, フロ
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 Gitのコミット単位で動的にDockerイメージをデプロイするプロキシサーバpoolというソフトウェアがあります。 poolとは poolは、WebアプリとDockerfileをGitで管理している場合に、コミットidをサブドメインとして（ http://<commit-id>.pool.dev/ ）poolにアクセスするだけで、そのGitレポジトリのコミット時の状態でWebアプリのDockerイメージをデプロイし、Webアプリのポートへとリバースプロキシして、Webアプリのレスポンスを返します。もちろん、コミットidをキーに複数の状態にどんどんアクセスできます。（mod_mrubyのユースケースを調査していてたまたま見つけました）。 このp
最近ようやく開発ツールとして Docker が手に馴染んできたので、タイトルの件も含めていくつか雑多に書きます。 CLI ツールを Go で書いて Docker イメージとしてリリースする コマンドラインツールを Go で書く、というのは以前からやっていて、主な理由としては「クロスコンパイルができるのでバイナリリリースが簡単」というのがありました。便利なので、クロスコンパイルから GitHub へのリリースを一発でやってくれるラッパーツールを書いたこともありました (一応動くものの、開発は非常に中途半端なところで止まってますが) gox して ghr するツール ggallin 作った その後、2017 年に入って Docker で Multi-Stage Builds という機能が実装されてからは、Dockerfile 内の build ステージで go build したバイナリを最終的
はじめに DockerでコンテナイメージをbuildするときにはDockerfileにOSイメージの指定や導入パッケージ、実行したいコマンドなどを記述してパッケージングします。 このDockerfileはほぼコマンドべた書きのような形なので難しいわけでは無いのですが、実行処理が多くなればなるほど長く読みづらくしまうし、テストも大変です。また既にChefやPuppet、Ansibleなどの構成管理ツールを用いているのであれば、既存の資産をうまく流用したほうが楽が出来ます。 ということで、Dockerfileにはほとんど仕事をさせずに、Dockerfileからchef-soloをキックしてコンテナをプロビジョニングしてみました。 やってみた ファイル構成は以下のような形です。今回はopscode謹製のbuild-essentialをレシピとして用意しました。 . ├── Dockerfile
もこです。 「各種アプリケーションのバージョン管理が面倒」 「Dockerfileにするほどでもないけどコンテナの中で実行したい」 などなど、作業マシンを汚したくないときなど結構あると思います。 Dockerfileなどでアプリケーションのみを入れたコンテナとは違う使い方をした、「作業用コンテナ」を作ってみました。 ベースのコンテナを作る まずは最新のUbuntuのコンテナの中に入ります docker run --name="dev_container" -it ubuntu:latest コンテナに入ったらパッケージを更新し、開発環境などに必要なパッケージ類をインストールしていきます。 apt update -y apt install curl vim git net-tools build-essential -y # などなど、必要なパッケージを入れていきます 今回はNode.js
はじめに 最近、検証環境を構築するにあたり Dockerfile を書き始めるところから入るカワハラです。おはようございます。で、結局、当初の検証目的を忘れて Dockerfile 書きに没頭してしまって色々と滞っております...つきましては、Dockerfile を書くにあたってのメモを残しておきたいと思います。あくまでも「私的」なベストプラクティスですのでご注意下さい... 参考 以下のサイトを参考にさせて頂きました。 Dockerfile Best Practices http://docs.docker.io/en/latest/examples/ Build Images (Dockerfile Reference) DockerでJava Webアプリケーションの検証環境を構築する How to Use Entrypoint in Docker Builder 「私的」なベスト
概要 Dockerコンテナ内にmysqlサーバを立てます。 mysqlアカウントを作成したり、mysqlサーバを外部に公開することも行います。 動作確認を行った環境は、ホストOS, コンテナOSともにCentOSです。 そもそもDockerとは 仮想環境構築に docker を使う - apatheia.info を読んでください！ Dockerfile さっそくですが、以下が Dockerfile です。 コンテナイメージを作成するために必要なファイルです。 # DOCKER-VERSION 0.3.4 FROM centos:6.4 # ここは自由に変えてください MAINTAINER Taro Tanaka # パッケージインストール RUN yum install -y mysql mysql-server # mysqlサーバのセットアップ RUN echo "NETWORKIN
Docker でフロントエンドとAPIを開発してみた
Visual StudioがKubernetes対応。DockerfileとHelmチャートを自動生成し、Kubernetes環境へデプロイ可能に
Visual StudioがKubernetes対応。DockerfileとHelmチャートを自動生成し、Kubernetes環境へデプロイ可能に マイクロソフトは、Visual Studioを用いてKubernetesに対するアプリケーション展開を容易にするツール群「Visual Studio Kubernetes Tools」のプレビュー版を公開しました。 Visual Studio Kubernetes Toolsを用いることでKubernetes環境へのデプロイに必要な設定ファイルを自動生成し、すぐにデプロイできるようになります。 DockerfileとHelmチャートを自動生成するVisual Studio Kubernetes Tools Visual Studio Kubernetes Toolsをインストールすると、Kubernetes対応のアプリケーションを開発するプロジ
ども、大瀧です。 データベースやクラウドストレージにアクセスするために、DockerコンテナでパスワードやAPIトークンキーなどのいわゆるクレデンシャル(資格)情報を扱うことがあります。これらの情報の扱い方についていくつかパターンを挙げ、考察してみたいと思います。 TL;DR(要点) DockerイメージやDockerfileに埋め込むのはアンチパターン コンテナ実行時に環境変数で渡すのがメジャー。しかしクレデンシャル管理が不要になるわけではない コンテナ実行時に外部から動的取得するのがおすすめ。クラウドのメタデータサーバーの利用がお手軽 クレデンシャル情報とは クレデンシャルは、コンテナから外部のデータソースにアクセスするための資格情報を指します。典型的なクレデンシャルとして以下があります。 DBユーザー名とDBパスワード : dbuser/dbpass WebサービスにアクセスするAP
GitHub Actions上のRustアプリのDockerイメージビルドを高速化する - blog.endflow.net
Rust + Docker + GitHub Actions = めちゃ遅い 以前、GitHub Actions 上の Rust ビルドを高速化する記事を書いたけど、 今回は Kubernetes 環境にスムーズに移行できるよう Docker イメージ化するという要件も加わったことで、改めて試行錯誤する必要が出てきた。 それぞれに対するビルド速度の最適化は存在しているものの、３つ (Rust, Docker, GitHub Actions) すべてを満たすとなるとコピペで終わるほど情報がまとまってないし、見つけた Tips もちょっと古かったり、これというものは見つけられなかった。 公式ドキュメントを見ると正当進化していて新しいオプションが生えていたりしたので、賞味期限は短そうだけど、自分の試行錯誤の結果を残しておこうと思う。 成果としては 12 分 22 秒かかっていた Rust アプリ
以下の内容は、他の記事で分かりやすく説明されているのでここでは省きます。 Docker / Docker Compose のインストール方法 基本的な使い方（といっても、私が知らなかっただけで一般的な使い方を挙げているかもしれませんがそこはご了承ください また、dockerコマンドオプションとdocker-compose.ymlのオプション指定は適宜読み替えてください。 では早速行きましょう！ Docker コマンド 1. build 時にキャッシュを使わない Dockerfileを編集しても内容が反映されないときは試してみてください。
![[Docker] 初心者が知っておくと便利かもしれない18の知識 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/ba620a70986bd5deaa8d2b4cbc4cf90095b7c85e/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCRG9ja2VyJTVEJTIwJUU1JTg4JTlEJUU1JUJGJTgzJUU4JTgwJTg1JUUzJTgxJThDJUU3JTlGJUE1JUUzJTgxJUEzJUUzJTgxJUE2JUUzJTgxJThBJUUzJTgxJThGJUUzJTgxJUE4JUU0JUJFJUJGJUU1JTg4JUE5JUUzJTgxJThCJUUzJTgyJTgyJUUzJTgxJTk3JUUzJTgyJThDJUUzJTgxJUFBJUUzJTgxJTg0MTglRTMlODElQUUlRTclOUYlQTUlRTglQUQlOTgmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtY2xpcD1lbGxpcHNpcyZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWJmM2E5NWI0MmE3MTFlMDBjZDJjN2QyODdmNWNmMjI1%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwZW50YTA3MDEmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWRjZDE0MWYyZWE1NDdmZTdhYjU5OTViZWYyZWE0ZWMy%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D984392e5410ea6fb02904d9f335a8200)
CircleCIでDockerコンテナに対してansibleを実行しserverspecでテストをする · さよならインターネット
November 13, 2014 参考 KAIZEN platform Inc. における運用自動化 - Speaker Deck Continous Integration and Delivery with Docker - CircleCI TL;DR CircleCI上でDockerコンテナを立て、 そのコンテナに対してプロビジョニングを行い、 プロビジョニング後のコンテナに対してテストを行う DockerコンテナにAnsibleを実行する コミットする度にDockerのimageをpullするのは時間がもったいないので cache_directoriesを利用し、imageをexportしておき 実行時にimportするようにすると多少速くなる。 . ├── Dockerfile ├── ansible/ └── circle.yml Dockerfile FROM kenji
ローカルで開発していたアプリをDocker化してみた（nginx+Flask+postgres） - Qiita
はじめに ローカルで作った簡易的なブログサービス（こちらの記事を参照）をDocker化してみました。正直この規模だと単一コンテナで十分だと思いますが、折角dockerをお勉強する機会なので、nginx（Webサーバ）とgunicorn+flask（APサーバ）とpostgre（DBサーバ）でコンテナを分けて、docker-composeで全コンテナの統合管理をします。 docker構成 ディレクトリ構成 ローカルの任意の場所にこの構成で作ります。 TutorialBlog ├docker-compose.yml ├nignx/ │ ├nginx.conf │ └Dockerfile ├app/ │ ├templates/ │ │ └(略) │ ├static/ │ │ └(略) │ ├app.py │ ├models.py │ └Dockerfile ├postgres/ │ ├initd
原文：Compose file version 3 reference https://docs.docker.com/compose/compose-file/ docker-compose.yml で定義される各々のサービスは、特定の image か build を指定する必要があります。その他のキーはオプションであり、docker run コマンドラインのものと似ています。 docker run と同様に、Dockerfile で指定されたオプションがデフォルトとして尊重されます（例：CMD,EXPOSE,VOLUME,ENV）。そのため、docker-compose.yml で再び定義する必要はありません。 image タグや image ID の一部です。ローカルでもリモートでも構いません。ローカルに存在しなければ、Compose はイメージを取得（pull）します。
コンテナセキュリティについてなんとなく不安を感じている方に向けた、ドキュメントと無料ツールの紹介です！ 「コンテナセキュリティってなんか必要そうやねんけど、実際なにすんの？」 先日、我らがDevelopers.IO Cafeにおいて、クリエーションライン株式会社 (CREATIONLINE, INC.)様と共催で、以下のイベントを開催しました。 あなたのコンテナ運用大丈夫？コンテナセキュリティの考え方と対応策 - connpass 全部で3セッションで構成されているのですが、私の方では、「コンテナセキュリティ関連OSSの紹介」と題して、コンテナセキュリティこれから検討始めようという方に向けて、そのとっかかりに有用なドキュメントと無料ツールを紹介させていただきました。 ドキュメントもツールもどれも有用なものなので、コンテナセキュリティについて不安や必要性を感じている人は、これらの中から実際に
TIG/DXの渋川です。 ソフトウェアの世界では、ツールや言語の進歩があって、もはや古い知識になっているにも関わらず、古い知識がベストプラクティスと呼ばれて蔓延し続けている例があります。Dockerだと「RUNをまとめよう」というのがそうです。かつてはこれは常に行うべきプラクティスでしたが、現代だとそうじゃないケースもあり、デメリットもあります。 https://www.docker.com/company/newsroom/media-resources 1. ただファイルが増えるだけのケースであれば気にしなくていい次の2つのファイルで実験してみます。ベースイメージに、10MBのファイルを作成するコマンドをふたつ並べたものです。 FROM debian:bullseye-slim RUN dd if=/dev/zero of=dummy1 bs=1M count=10 RUN dd if
インフラの駒崎です。Jenkins の Pipeline スクリプトについてのお話です。 早速ですが Jenkins の Pipeline スクリプト、使われていますでしょうか。 もしかしたら以前ちょっと書いていたけどやめてしまったとか、従来の GUI 設定のほうが楽だ、となんとなく敬遠してしまっている方もいるのではないでしょうか。 私が実際そうだったのですが、最近になってやっと Jenkinsfile - Pipeline スクリプトが身近に感じられてきましたので、現状の簡単なまとめを書いてみたいと思います。少しでも似た状況の方へのヒントやきっかけになれば幸いです。 Pipeline スクリプトは難しい？ 私は正直、2016年に Jenkins 2 の目玉機能として Pipeline が出た当初は、とっつきにくい…わからん…と思っておりました。Jenkins を上っ面でなんとなく使ってい
クラウドネイティブ技術を日本にも浸透させることを目的に開催された「CLOUDNATIVE DAYS Spring 2021 ONLINE」。ここでVMwareの伊藤氏が「脱 Dockerfile！ Cloud Native Buildpacksとkpackを使った簡単で安全なイメージ」をテーマに登壇。まずは、Dockerfileの問題点とCloud Native Buildpacksについて紹介しました。 トーク内容の目次 伊藤裕一氏（以下、伊藤）：「脱 Dockerfile！ Cloud Native Buildpacksとkpackを使った簡単で安全なイメージ」という内容について、伊藤がお話しします。 目次です。最初にDockerfileのおさらいと、問題点を話します。そして、Dockerfileを使わずにビルドを実施するCloud Native Buildpacks（CNB）の概要と
serverspecとdocker-apiでDockerfileをTDD いくつかDockerfileを書いてきた．今書いているDockerfileは短くてシンプルなものばかりだが，もっと長く複雑化した時に不安になりそうだ．不安を解消するにはテストしかない．さらにテスト駆動的にDockerイメージを開発できたら素敵だ．つまり， テストを書く Dockerイメージを作成して，テストの実行 -> RED Dockerfileの編集 Dockerイメージを作成して，テストの実行 -> GREEN テストを… の流れができるとよい． ということで，RSpecを使ってTDDでDockerfileを開発するというのをやってみた，tcnksm/docker-rspec．今回実現したのは以下． Docker Remote APIでDockerfile特有のコマンド(e.g, CMDやEXPOSE)のRSp
Bitbucket における Docker 自動ビルドを発表 | Atlassian Japan 公式ブログ | アトラシアン株式会社
私のブログを頻繁に読んでくださってる皆さんは、私がどれだけ Docker に夢中かご存知ですよね。それから Git にも。今日は、そんな私の興奮が伝わるようなお知らせがあります。Docker の自動ビルドが Bitbucket に統合されました! Docker とは何か? 単純に言えば、Docker はプロビジョニングとデプロイの自動化分野における次の大物です。Docker では、OS、データベース、環境変数、start/stop スクリプトなど、アプリケーションを実行するのに必要なあらゆるものを定義することができます。そして、その定義をテキストファイルに保存することで、イメージを再利用、更新、共有できます。 Docker を使用すると、アプリケーションや環境を修復するよりも楽に (安くという意味で) 作り直すことができます。ここまでですでに開発者の皆さんは、ローカルワークステーションに対
追記: 実際に運用する際はライセンスにご注意ください: 公開用DockerイメージにAndroid SDKを含めるのはライセンス違反という話 - Islands in the byte stream 三行まとめ 社内のJenkins環境 / Travis-CI / Circle-CI など、CIサービスごとにビルド設定を調べるのにうんざりしたのでDockerizeしてみた 手元とCI環境がまったく同じになるので一度動くようになったら安定して動かせるはず とりあえずCircle-CIで試して動いた 前提 OSXの場合、boot2dockerとdockerをhomebrewで入れましょう。boot2dockerはdockerを動かすためのVMとLinuxイメージを適当に整えてくれるやつです。 brew install Caskroom/cask/virtualbox # まだ入れてなければ b
executableの場所を探すときwhichではなくcommandを使う習慣 - yujioramaの日記
whichを使わない一番の理由はcoreutilsに入ってないから（commandはたいていのshellでbuiltin functionになっている）。 ash(1): command interpreter - Linux man page dash(1) - Linux manual page Bash Builtins (Bash Reference Manual) たぶんDockerfileでいろいろやっているときに身についた振る舞いだと思う。 ポータビリティを高めるとかの高い意識ではなく、何度もcommand not foundに遭遇して面倒になったことが主な動機で、そこから派生してwhichコマンドの存在を無視する（頼らない）ようになった感じ。 あと、軽量なDockerイメージを作るのがかっこいいと見做された時期があって（時期というより原則だけど）、インストールするパッケージ
Docker 1.5の変更点
Docker 1.5の変更点 Docker 1.5.0-rc1 Docker 1.5: IPv6 support, read-only containers, stats, “named Dockerfiles” and more | Docker Blog Docker 1.5が出た．IPv6のサポートやstatsコマンドによるコンテナのメトリクス表示などが追加された．ユーザ的に一番嬉しいのはDockerfileの名前を自由に決められるようになったことだろうと思う． 今までDockerfileはDockefileという名前しか受け付けなかった，というかまともに動かなかった．やりようはあって，標準入力からぶっ込むことはできた．例えばbaseとう名前のDockerfileを作って以下のようにbuildを実行することができた． $ docker build -t tcnksm/test - <
業務やプライベートでのハンズオンを通して得た知見を元に、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
背景 Dockerfileを静的解析したいと思い便利なツールがないかと探していたら発見しました。 DockerfileのLintツール ◆ hadolint/hadolint エラーが出るDockerfileをビルド前に検知してくれます。 ちなみにHaskellで書かれているようです。 現時点での最新バージョンはv1.15.0でmac等にも対応している。 GitHubのスター数は1000程である。 lintとは wikiより引用 lint とは、主にC言語のソースコードに対し、コンパイラよりも詳細かつ厳密なチェックを行うプログラムである。 型の一致しない関数呼び出し 初期化されていない変数の参照 宣言されているが使われていない変数 同じ関数を参照しているが、戻り値を使う場合と使わない場合がある[疑問点 – ノート] 関数が戻り値を返す場合と返さない場合がある など、コンパイラではチェックさ
おなじみの画像 JavaやScalaといったJVM言語のDockerイメージは、JVMを同梱しなければならない都合で肥大化しがちである。特に何もしなくても、例えば一般的なamazoncorretto:21のイメージサイズは217.7 MBもある。 hub.docker.com これにさらにビルド済みのJARファイルが載ってくるので、結構大きくなってしまうのだ。 そこで、Scalaのコンテナイメージのサイズをなんとか小さくできないかと、考えた。すると、JVMを使ったまま70 MiBくらいに縮めることができた。 github.com コンテナイメージのサイズを小さくするために、何をしたかを書いていく。ちなみに題材としたアプリケーションはちょっとしたHello, Worldをするだけのもので、ライブラリはCatsに依存させた。 JVM使う編 マルチステージビルドを行う Alpineなどの軽量ラン
こんにちは。 技術チームの星野と申します。 社内勉強会で、Dockerfileの作り方とか、CoreOSでのDockerでのデプロイ方法の一例を紹介しました。 ↑はその際のスライドです。前半のポエムっぽい序章は、適当に読み飛ばしていただければと思います。 個人としてDockerを試している理由は、構成管理をDockerfileというシンプルな形式で記述しようとしているところが魅力的だったからです。 「CoreOSの発表」と言いつつ、デモでは「CentOS7」も使ったりしました(CentOS7がリリース直後だったから!!)。 CentOS7ではsystemdがデフォルトで動いており、弊社ではCentOSを採用しているサービスも多いため、ここぞとばかりに試させていただきました。 補足 あと、スライドの補足として、今回デモで動かしたCoreOSの起動〜Jenkinsコンテナ起動までのスクリプトの
エムスリーエンジニアリンググループ AIチームの笹川です。 バスケと、ロードバイクが趣味なのですが、現在、NBAのplayoffと、Tour de Franceが同時に開催されていて大変嬉しい毎日を過ごしています。 特にNBAのplayoffは、連日overtimeとなるような激戦や、giant killingがあったりのアツい戦いが繰り広げられていて最高です。 そういう状況なので（？）、今回は先日取り組んだ、Pythonの機械学習バッチを実行するdocker imageのサイズ削減についてのアツい戦いについて紹介したいと思います。 膝の上に登って寝る為に、筆者がデスクに戻るのを机の下で待ち構える犬氏（かわいい） 今回の取り組みでは、もともと3GB程度だったPythonのML用のimageを、約2.0GBに削減することができました（それでもなかなかのサイズ。MLのimageは特に大きい印象
buildkit/frontend/dockerfile/docs/syntax.md at dockerfile/1.4.3 · moby/buildkit
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Googleは2018年7月10日（米国時間）、コンテナを効果的に作成するための7つのベストプラクティスを「Google Cloud Platform」の公式ブログで紹介した。概要は以下の通り。 （1）コンテナごとに1つのアプリケーションをパッケージングする コンテナは、内部で1つのアプリケーションが実行されるときに最も効果的に機能する。このアプリケーションは、親プロセスが1つでなければならない。例えば、同じコンテナでPHPとMySQLを実行してはならない。コンテナごとに1つのアプリケーションをパッケージングすれば、アプリケーションのライフサイクルに合わせてコンテナのライフサイクルを管理できる。 （2）PID 1とシグナル処理、ゾンビプロセスを適切に扱う KubernetesとDockerは、コンテナ内のアプリケーションを停止するために、Linuxシグナルを送信する。このシグナルは、プロセ
Products Docker DesktopContainerize your applicationsDocker HubDiscover and share container imagesDocker ScoutSimplify the software supply chainDocker Build CloudSpeed up your image buildsTestcontainers Desktop Local testing with real dependenciesTestcontainers Cloud Test without limits in the cloud See our product roadmapMORE resources for developers
CircleCI + DockerでサーバCI始めました | feedforce Engineers' blog
はじめまして！今年１月からジョインしましたtjinjinです。feedforceではアニメインフラを担当しています。ちなみに今季オススメアニメはSHIROBAKOです。 今回サーバCIにDockerを導入しましたので、実際の設定や工夫した点など投稿したいと思います。 feedforceのサーバCI 弊社ではこれまでCircleCIまたはJenkinsとAWSを組み合わせてサーバのCIを行って参りました。 参考: JenkinsでサーバのCIを始めました しかし、CircleCIを利用するプロジェクトが増えるにつれ、CircleCIに実行待ちが発生するようになりました。CircleCIの実行ログを確認したところ、AWSのセットアップに時間がかかっていることがわかったので、環境のセットアップ時間を短縮できるもののはないかと探していました。そんな折、Dockerがいいのではという話を耳にしました
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DockerでRailsの開発環境を構築する | DevelopersIO
機械学習のための環境構築とその管理 - nykergoto’s blog
seroku.jp - このウェブサイトは販売用です！ - seroku リソースおよび情報
Docker を本番環境で４ヶ月運用して分かった HARD THINGS – Stay Creative !
複雑な構成のrailsアプリをdockerで動かしたい場合はどうするべきか - Qiita
Gitのコミット単位で動的にDockerイメージをデプロイするプロキシサーバpool
CLI ツールを Go で書いて Docker イメージとしてリリースする
Dockerイメージをchef-soloでプロビジョニングする | DevelopersIO
Dockerでサクッと使い捨ての開発環境を用意する | DevelopersIO
Dockerfile の書き方「私的」なベストプラクティス - ようへいの日々精進XP
Dockerコンテナ内にmysqlサーバを立てる - Qiita
さくらのエンジニアがコンテナ利用術を公開！ 〜「さくらの夕べ Docker/Kubernetesナイト」レポート | さくらのナレッジ
Dockerコンテナのクレデンシャル設計パターン | DevelopersIO
[Docker] 初心者が知っておくと便利かもしれない18の知識 - Qiita
Docker Compose - docker-compose.yml リファレンス - Qiita
コンテナセキュリティを始めるための無料ツール5つとドキュメント3つの紹介 | DevelopersIO
DockerでRUNをまとめた方が良いとは限らない | フューチャー技術ブログ
Jenkinsfile、書いてますか？ | GREE Engineering
Dockerfileの属人化による脆弱性を防げ ベストなイメージが作成可能なCloud Native Buildpacksの使い方
serverspecとdocker-apiでDockerfileをTDD
AndroidのCIはDockerでビルドするのが楽 - Qiita
Dockerfileのベストプラクティス - Qiita
dockerfileの静的解析ツールが便利すぎた - Qiita
ちっちゃなScalaコンテナを作つコツ(6 MiBだぞ) - Lambdaカクテル
個人で使ってみた Docker とCoreOSとか | feedforce Engineers' blog
Pythonの機械学習用Docker imageのサイズ削減方法の紹介 - エムスリーテックブログ
Google、コンテナ作成の7つのベストプラクティスを公開
Introducing Dockercast – the Docker Podcast | Docker Blog