DockerとSELinux - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
Javaプロジェクトにおけるリリース周りの手法あれこれ - Kengo's blog
考慮する点 成果物のデプロイ ビルドの成果物（artifct）をアップロードすること。アップロードと公開は分けて考えることに注意。デプロイ先にはいくつか候補がある： GitHub Packages (旧GitHub Package Registry) Maven Central Repository Docker HubなどのDocker Registry GitHub Packagesはコンテナも.jarもまとめて置けるが、コミュニティ標準の場所ではないので利用する際にひと手間必要になる。プライベートプロジェクトの場合は積極利用することになりそう。FOSSなら基本的にMaven Centralに置くことになる*1。プロジェクトによっては.jarファイルとしてではなくコンテナとしてデプロイすることもあるだろう。 リリースノートの作成 CHANGELOG.mdやsrc/site以下のファイル
Dockerセキュリティ: 今すぐ役に立つテクニックから，次世代技術まで
Visual Studio Users Community Japan #1 で発表した資料になります。 https://vsuc.connpass.com/event/143114/
root権限無しでKubernetesを動かす
user namespaceを用いて，Kubelet及びCRI・OCIランタイムを非rootユーザで動作させることにより，Kubernetesのセキュリティを強化する手法をご紹介します． https://k8sjp.connpass.com/event/120074/
Docker に正式統合された BuildKit の buildctl コマンドで Dockerfileを使わずにコンテナイメージをビルドするハンズオン - Qiita
こんにちはpo3rinです。日本語解説があまりなかったので buildctlコマンドをセットアップを行い、 docker build を使わずに コンテナイメージをビルドする過程を紹介します。OS は Mac OSX を想定してます。 BuildKitとは BuildKitは、命令からイメージレイヤを作成するための操作を行うツールキットです。Buildkit === 次世代 docker build という表現で説明されることも多いですが、Buildkit 自体は Docker とは別物です。そもそも Docker は moby という OSS から作られており、その中の moby/buildkit がイメージレイヤを作成する責務を持ちます。ゆえに、Buildkit は次世代の機能を持ったビルドツールキットと言った感じで、docker build はそれを単に利用していると言った感じです。
Docker を用いてソフトウェアをデプロイするとソフトウェアの品質が上がる - Diary
Docker を用いてソフトウェアをデプロイするとソフトウェアの品質が上がる http://b.hatena.ne.jp/entry/bonotake.hatenablog.com/entry/2018/09/06/072800 ここをながめていて思ったことなんですが。 Docker はデプロイにのみ関連するツールであって、ソフトウェア開発の本質には一切関係ないものだ、という考えの人をたまに、いや、よく見る。これは全く間違っていて、 Docker を用いて継続的にソフトウェアをデプロイしているだけでソフトウェアの品質は上がります。ソフトウェアの品質のような問題について考えている人は Docker とそのメンタルモデルに興味をもつべきです。 本来こうした問題について僕がなにかを言う必要はなくて The Twelve-Factor App という文章を読めば十分です。あるいは 大切なことはだい
Docker is the dangerous gamble which we will regret | Smash Company
May 13th, 2018 In Technology 45 Comments If you enjoy this article, see the other most popular articles If you enjoy this article, see the other most popular articles If you enjoy this article, see the other most popular articles (written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: lawrence@krubner.com, or follow me on Twitter. Also read: “My fina
Dockerコンテナが遅くなるもう一つの原因 | POSTD
前回の ブログ記事 では、Kubernetesの話と、 ThoughtSpot がKubernetesを開発インフラのニーズに合わせてどのように取り入れたかをご紹介しました。今回はその続報として、最近の興味深いデバッグ経験について少々駆け足になりますがお話ししていきます。本記事も「コンテナ化と仮想化はノットイコールである」という事実に基づいており、たとえcgroupの上限がどれも高くない値に設定されホストマシンで十分な演算能力が利用できるとしても、コンテナ化されたプロセス同士がリソースの競合を起こす場合があることを示したいと思います。 ThoughtSpotでは内部のKubernetesクラスタで 多数のCI/CDや開発関連のワークフロー を稼働させており、ある1点を除いては全てが順調でした。唯一問題だったのは、ドッカー化された製品コピーを起動すると、パフォーマンスが期待を極端に下回るレベ
docker-composeをサポートしたCodefreshというCIサービスを使ってみた
CodefreshというDockerを使えるCIサービスがあるので雑に触ってみたというエントリです。 Docker-Native Continuous Integration and Delivery with Codefresh プラン プランについては各自確認してほしいんですが、基本的にPublicなリポジトリを扱い並列ビルドが要らなければ無料で使うことができます。 Open SourceプランでもGitHub/BitBucket/DockerHub/Slackは対応 Basic($99/month)からは並列ビルドができ、プライベートリポジトリも扱うことができる Pro($299/month)からはJenkinsやbintrayとも連携ができ、インフラは共有領域ではなく専有領域を用意してもらえる。**On-Premise Git Support**という記述があるので、GitHub
【翻訳版】Docker, Inc is Dead - comix
What's this? Docker, Inc is Dead の翻訳記事です。 ご本人の許可は取っていますが、僕が英語ペラペラではないため、読み辛いのはもちろん、一生懸命訳してはいますが誤訳・ミスリードなどあるかもしれません。 ですので、100%正確な内容を把握したい方は原文をお読みください。また、ここ間違ってるよ！ニュアンスが違うんじゃない？などありましたらお気軽に（優しく）コメントいただけると幸いです。 Docker, Inc is Dead / Docker社は死んだ Dockerにとって、2017年は非常に辛い1年だったと言っても過言ではありません。Uberを除いて、より活用され、賞賛され、十分に資金提供を受けたシリコンバレーのスタートアップの中で、Dockerが2017年に行ったような悪手を打ったスタートアップは思い浮かびません。人々は2017年を、ソフトウェアの偉大な一部分
Docker, Inc is Dead
DISCLAIMER: The views expressed in this article are solely mine. They do not reflect the opinion of my employer, nor that of any group I am affiliated with, sponsored by, or employed by. Please read my Disclaimer before breaking out the tar and feathers. To say that Docker had a very rough 2017 is an understatement. Aside from Uber, I can’t think of a more utilized, hyped, and well funded Silicon
会社の本番環境をDocker(ECS)に置き換えるために準備したこと気づいたこと
エンジニアの@macs_6です。 このブログでは社内のAWS EC2上で運用しているアプリケーション群をECS移行したプロジェクトについて紹介します。 ローカルの開発環境をDockerした話は以前の記事(複数の rails プロジェクトが共存する開発環境を Docker 化した話を晒してみる)で西辻が紹介しているので、そちらを参照して下さい。 概要 プロジェクトを始める前に感じていた課題 目指す状態 ECSを選択する理由 設計 移行のために必要な作業 Digdagによるスケジューリングについて ECSを使って見て気づいたこと 今後やりたいこと プロジェクトを始める前に感じていた課題 ローカル・本番で再現性のある環境を簡単に作れるようにしたい 簡単にスケールできるようにしたい コストを抑えたい ECS移行プロジェクトを始める前にはこれらの3つの事に課題感を持っていました。 1.ローカル・本番
Dockerfileはなぜ複雑になるのか - Qiita
はじめに Dockerfileとは docker imageを作成する際のコマンドをコード化したもの 公式ドキュメント Dockerfileは「コンテナを動かす」ためだけなら簡単に作成することが出来るが、工夫せずに書くと運用上いろいろな問題が発生する。 それらの問題点のほとんどは書き方のテクニックによって回避することが出来るが、それらのテクニックを駆使すると、今度はDockerfileの中が複雑になっていく。 Dockerfileはなぜ複雑にならざるを得ないのか 発生する問題とそれに対するテクニックを例を上げて説明していくことで理解してもらう。 rails5.1 hello world projectを例に説明する。 簡単なDockerfileの例 重要なのはFROMとRUNとCOPYのみ FROM ベースとなるimageの指定 https://docs.docker.com/engine
多機能なコンテナクラスタ構築ツール「Kontena」 | OSDN Magazine
Dockerの普及に伴い、昨今ではDockerを使ったさまざまなクラスタ構築ツールが登場している。今回紹介するKontenaもそのようなクラスタ構築ツールの1つで、多機能かつ構成が容易で、またさまざまな環境で利用できるのが特徴だ。 多機能でかつ構成が容易なDockerクラスタ構築ツール Linuxによるインフラ関連において、ここ数年で最も注目されていると言っても過言ではないDockerだが、開発当初は単一のサーバーでの利用にのみフォーカスして開発が進められており、複数のマシンを連ねたクラスタ環境でDockerを利用するためには、サードパーティ製のツールが必要となっていた。その代表的なものに「Kubernete」や「CoreOS」があるが、今回紹介するのはそれらとは別のアプローチを採用したコンテナクラスタ環境構築ツール「Kontena」だ。 KontenaもKuberneteやCoreO
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Dockerfile書きたくないでござる
Enterprise Container Platform | Docker
Codefresh | The World's Most Modern CI/CD Platform with GitOps
Wait – we can explain, says Moby, er, Docker amid rebrand meltdown
Dockerを本番で使ってみて分かったこと
type Type