はじめに やめろ、ではなく、やめたほうがいい。です。自分のユースケースに合ってるか今一度確認することを推奨します。基本的にはAlpineは避けたほうが良い、というのが2021年時点での私の認識です。 なんで？ libcに一般的な互換性が不足しているからです。Ruby、Python、Node.jsなどでNativeモジュールをバンドルしているアプリケーションの場合、パフォーマンスの劣化や互換性の問題にぶち当たる場合があります。 superuser.com あとは他のベースイメージの軽量化もそれなりに進んできていて、Alpineが定番軽量イメージと言う認識は2018年頃には消えつつあったかなという認識でいます。 どうすりゃええねん ※Debian Slimがあるやんってツッコミ結構もらったんですが、Slimは当たり前過ぎてもう紹介しなくていいかなっていう甘えで省略していました。よろしくおねがい

コンテナ技術入門 - 仮想化との違いを知り、要素技術を触って学ぼう コンテナ技術を適切に活用するには、コンテナが「どうやって」動いているかを学びたいところ。はてなのエンジニアhayajo_77さんがコンテナの要素技術の勘所を解説します。 こんにちは。株式会社はてなでサーバー監視サービス「Mackerel」のSREを務めるhayajo_77（ @hayajo ）です。 さて、コンテナ技術はDockerの登場がきっかけとなり、本格的に活用が始まりました。現在はKubernetesを始めとするコンテナオーケストレーションツールや AWS, GCP, Azure などのクラウドサービスで提供されるコンテナマネジメントサービスを採用したサービス運用事例が数多く紹介されており、コンテナ技術は「理解する」フェイズから「利用する」フェイズに移ってきています。 コンテナそのものは上記のツールやサービスにより

2017年にもうコンテナの未来・一つのカタチはもう確定したと言え、今更感があるものの、改めてDockerとコンテナについて。 今更こんなことを書くのは、情報が溢れてくる今こそ、正しく理解し、正しい順序で学習することが重要だと切に思うから。 内容についてのお断り How Toはかきません あくまでも2018年時点の私見 目新しい情報はない、2016年頃に書けたレベル Dockerをこう使えとか、こうするのがいいとかの話ではなく、コンテナとDockerに関して大きな視点で現時点で私の考えを書きます。また、私自身はかなりのコンテナ推進派です。 Dockerをよくわかっている人には意味のない記事となります。 コンテナ(Docker)のメリット 何故コンテナがいいのか、コンテナをある程度の学習コストを払ってでもやる理由 コンテナとDocker コンテナ技術はDockerが生まれる前から存在する技術で

JAWS DAYS 2018

引用:Docker run リファレンス ここでは--memory-reservationと--oom-kill-disable=false、--memory-swappinessについて調べました。 環境 OSX 10.12 Docker for MAC(docker 1.12.1) --memory-reservation メモリのソフトリミットということで、ホストのメモリに余裕がある時はは制限はかからず、他に使用している時は制限がかかるということらしい。 試してみました。 コンテナ2つ起動し、1つは--memory-reservationを512MB、もうひとつは制限なしで設定します。Linuxの負荷ツールstressで以下のシナリオでメモリに負荷をかけます。 前提：ホストのメモリは2GB 1. 両方のコンテナに1.25GBの負荷をかける 2. メモリ制限のないコンテナへの負荷を停止

Dockerで開発、ステージ、本番へのリリースから運用までを一通り行った結果、どのようなことに注意して開発すべきか、どのような構成をとるべきか、どうやって本番リリースするのかについてまとめます。Laravel, Lumenを使っていたため、PHPで開発を行っている方たちにとっても、本番導入を検討するにあたって良い目安になるかと思います。

Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

以前に私が書いた「 Dockerの本番運用：失敗の歴史) 」という記事は、非常に多くの反響を呼びました。 その後、長い議論を交わして、何百件ものフィードバックや何千件ものコメントを読み、さまざまな人々や主要事業者とも顔を合わせました。Dockerでの試みが増えるほど、その失敗談は増えていきます。そうした現状を、今回アップデートしておきたいと思います。 この記事では、最近の交流や記事から得た教訓を紹介しますが、その前に簡単におさらいをして軽く背景を説明しましょう。 免責事項：対象読者 たくさんのコメントから、世の中には10種類の人々が存在するということが明らかになりました。 1) アマチュア 実際のユーザがいない試用版のプロジェクトやサイドプロジェクトを実行している人々です。Ubuntuのベータ版を使用するのが当然だと考えており、「安定したもの」は古いものと見なすようなタイプです。 注釈：書

Dockerconf2017で発表のあったlinuxkitとMoby Project。 デモを見て衝撃を受け、今後のDockerに新たなImmutable infrastructureの可能性を感じたので調べたり試したりしてみました。 実際に動かしてみたスクリーンショットも載せてあります。 皆さんにも僕の感じた衝撃と可能性を知ってもらいたいです。是非最後まで読んでいってください！ (20170419 10:00 編集) Moby Projectとlinuxkitについて認識が違っていたことに気付いたので修正しました。 これを読んでわかること Moby Projectとlinuxkitの概要 mobyを使ってbuildやrunをする方法 mobyを使ってGCPでインスタンスを立てる方法 環境 OS: MacOSX Sierra Go: version 1.8.1 docker: versio

わーい！コンテナたのしー！🐾 こんにちは。流行りには積極的に乗っていきたい。インフラエンジニアの光野です。 弊社が運営するファッションサイトIQONでは、日々200以上の提携ECサイトから100万のオーダーで商品をクロールしています。 新商品の追加・商品の在庫状況・セールの開催など情報は日々変化するため、弊社において「正しくクロールすること」と「速くクロールすること」は肝心カナメの要素です。 本記事では、特に「速くクロールする」という目的で構築したコンテナベースの新クローラーシステムを紹介いたします。 このクローラーシステムは、最終的にクロール時間67%減、 維持コスト70%減という成果が得られました。 キーワード： コンテナ, Docker, Apache Mesos, Marathon, AWS Lambda, Amazon EC2 SpotFleet 問題解決手段の検討 -> コン

Google、DockerコンテナのビルドをREST APIなどで自動化できる「Container Builder」リリース。1日あたり120分のビルド時間まで無料 ソフトウェアの開発サイクルを迅速にまわすうえで、開発したコードをビルドし、テスト環境でテストをし、本番環境へ展開するといった操作を自動的に行う、いわゆるCI/CD（継続的インテグレーション／継続的デリバリ）の仕組みを構築することは欠かせないものになろうとしています。 こうしたCI/CD環境を構築するにあたって便利なのがDockerコンテナです。アプリケーションをDockerコンテナにパッケージすることで、軽量でポータブルなDockerコンテナの特長を活かして開発者が開発に利用しているノートPCからテスト環境、本番環境まで簡単に移動できるためです。 GoogleはこうしたDockerコンテナのビルドをRESTful APIを用い

Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

7年前に書いたRuby 1.8 + Rails 1.2.6 + MySQL 5.0のアプリがあり、ほとんど使ってないけど、たま～に使うので、扱いに困っていました。 そこで、今動いているミドルウェアのバージョンをそのままにDockerでコンテナ化して、どんな環境にも移動できるようにしました。これでどこでも昔のバージョンのまま動き続けることができる、いわるゆ塩漬けです！ それを紹介します。 Dockerの実行環境 CentOS Linux release 7.1.1503 Docker version 1.10.3, build 3999ccb-unsupported 塩漬け対象アプリの構成 ミドル Ruby1.8.7 Ruby on Rails 1.2.6 MySQL 5.0.77 アプリ bitbucketにあるレポジトリを/usr/local/myappにcloneして動作させる データ

WHY『変化に強いインフラ』を作ることで、技術にこだわり続ける環境ができ、ビジネスの変化にいち早くキャッチアップできます。 そのためにどのようにして、『変化に強いインフラ』を作ることが出来るのか模索したものをまとめます。 WHATKubernetes 上にアプリケーションを載せるCI/CD 環境構築GitHub Flow の開発スタイルでを元に QA で自分で書いたコードが確認でき、マージをしてmasterへpushしたら、Produciton へすぐにデプロイするサーバースペックを簡単に変えれる/内部で使われるライブラリ等も変更しやすいようにするDeploy の仕組みを自由に変更できるソースコードは以下です。 Github: koudaiii/jjug-ccc2016fall-devops-demoref. GitHub Flow 『変化に強いインフラ』を作っていく上での定義とルール変化

cloudpack大阪の佐々木です。 Amazon Linuxがコンテナ化され、ECSでもオンプレのDockerでも動かせるようになったようです。 https://aws.amazon.com/jp/blogs/aws/new-amazon-linux-container-image-for-cloud-and-on-premises-workloads/ 早速やってみます。 AmazonLinuxコンテナはECR上に保存されているので、ECRへのログインコマンドを取得します。リージョンはap-northeast-1でも取得できました。

Kubernetes 1.4リリース。Dockerコンテナのクラスタ構築が容易に、バッチ処理などの定期的実行に対応など Dockerコンテナはこれからのクラウドネイティブなアプリケーションのプラットフォームとして本命視されており、そのクラスタ運用管理ツール、あるいはスケジューラと呼ばれるツールの重要性が高まっています。 Kubernetes 1.4の主な新機能は以下です。 Dockerコンテナのクラスタ構成を容易に 新コマンド「kubeadm」の導入で複雑なスクリプトを不要にし、「kubeadm init」でマスター起動し、「kubeadmin join」でクラスタをノード化するという、2つのコマンドで簡単にDockerコンテナのクラスタを起動できるようになりました。 バッチ処理やデータベースなどのステートフルなアプリ対応を拡充 「ScheduledJob」コマンドが追加され、バッチ処理の

RubyKaigi 2016 http://rubykaigi.org/2016

2023年11月16日に開催されたAdobe MAX JapanのUI/UXショートセッションにて、株式会社ブックリスタ新規事業開発室デザイナーの黒野明子が発表した内容です。 --- 速攻で価値検証して無駄なものを作らないプロダクトデザイン 「気合を入れて完璧なデザインのプロダクトを作ったのに、サービスがクローズしてしまった…」という経験、あなたはお持ちではないでしょうか？ 世の中では数多くの新しいサービスやプロダクトが日々生まれていますが、実際に成功するものは限られています。しかし、初期段階でアイディアの価値を検証することで、不要なリスクを減少させ、成功への道筋を明確にしやすい様々な手法が存在します。 プロダクトデザイナーとしてそのような価値検証に役立つ手法を知っていたら、もっとチームに対して貢献することができるでしょう。無駄なものを作らず、本当に必要な部分に貴重なリソースを割くプロダク

本書はオープンソースのコンテナ管理ソフトウェア、Dockerの基礎から応用までを網羅した総合的な解説書です。はじめに開発環境をセットアップし、シンプルなWebアプリケーションのビルドについて解説した上で、コンテナの開発、テスト、結合に加えて、デプロイの方法、実動システムの効率的なモニタリングとロギングを紹介します。そして複数のホストからなるDockerコンテナのクラスタを、安全かつ高い信頼性の下で実行するために必要な高度なテクニックやツールについて紹介します。さらにネットワークやセキュリティについても詳述。Dockerとそのエコシステムを本格的に活用したい開発者、運用エンジニア、システム開発者必携の一冊です。 正誤表 ここで紹介する正誤表には、書籍発行後に気づいた誤植や更新された情報を掲載しています。以下のリストに記載の年月は、正誤表を作成し、増刷書籍を印刷した月です。お手持ちの書籍では、