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

今回やりたかったこと 社内で適用しているセキュリティのSaaSサービスのアップデートの自動化をしたい 処理内容は、基本的にapiをコールしてこねこねしていくだけ Lambdaでいいのでは？ SaaSが提供しているapiサーバーが、アクセス集中時だと5分経ってもレスポンスを返してくれない そこでAWS BATCH AWS BATCHとは Job queueを受けた段階で、予め指定しておいたスペック(スペックが足りなかったら自動で最適なものを立ててくれるらしい？)のEC2を立ち上げてECRからコンテナイメージを持ってきてタスク実行してくれる スケジュールを設定して実行してくれる！とかは無さそう。 アーキテクチャ Dockerfileはこんな感じ FROM centos:latest RUN curl -kl https://bootstrap.pypa.io/get-pip.py | pyth

VPC上でELBを作成する場合は、VPCのSubnetとELBの関係(Availability Zone編)の記事で紹介した通り、 サブネットを設定する必要があり、そのサブネットは各AZで最大一個、複数指定することができます。 このELBに設定したサブネットは途中で変更することも可能です。 まず、ELBに下記のようなサブネット(10.0.0.0/24 Aゾーン)が指定されているとします。 上記のように選択されているサブネットを、下記のようなサブネット(10.0.2.0/24 Aゾーン)に変更してみますが、 エラーが出力され、変更できません。 エラーは下記のように出力されており、ELBに設定されているサブネットを変更するには、 少なくとも二つのAZがELBに設定されている必要があるようです。 In order to change the subnet attached to your loa

AWSのVPC & Subnetのビットマスクは /16 – /28 です。この数字を聞いて 「狭い方はもう少し出来てもいいんじゃないか？」と私も思っていましたが、/28でも狭すぎます！特にELBを使う場合は、すぐにIPが尽きてしまいます。 なぜ狭いビットマスクを指定するのか？ VPNを張りたいので、CIDRの衝突を回避するため VPC Peering でのCIDRの衝突を回避するため 貧乏性 概ね別ネットワークとの接続が目的だと思います。私は、VPN接続が予定されているが、対向のCIDRが分からない、だから極力狭いサブネットを指定して衝突する可能性を下げる目的でつかいました。ただし、この用途では、ISP Shared Address(100.64.0.0/10)を使ってしまうのも手です。 狭いビットマスクとELB 早くも結論を書くと /28で使えるIPアドレスは、AWS側ルータ等に取られ

昔つかってたHatena Blogより転載 MariaDB Galera Cluster 5.5を試す oujiにMySQLの深淵の闇(マスタ昇格とかマスタ昇格とか)から逃れたいと相談したところ MariaDB Galera Clusterが良いと教えてもらったのでやっとこさ試した記録を残します。 RDS最高なのですが、選定できないと思われるケースもあるのでこっちが利用できたらいいな。 MariaDB Galera Clusterって何 デュアルマスタ構成が可能なデータベースクラスタらしいです。最高。 今回はMySQL 5.5からMariaDBへの移行を考え MariaDB Galera Clusterは5.5で試しています。 MariaDB 5.5はMySQL 5.5と互換性があるので、アプリケーションやデータベースを変更せずmysqldumpで移行できると思います。 詳しい資料は ここ

Uchiwa の Dockerfile を Docker Hub で Automated build した後 Webhook 機能で自動デリバリー（デプロイ）をやってみた cloudpack の 自称 Sensu芸人 の かっぱこと 川原 洋平（@inokara）です。 Dockerfile 発見 すでに自分の中で 2014 年ソフトウェア大賞にノミネートされている uchiwa ですが GitHub のリポジトリを眺めていて気づきました。Dockerfile が…。 作者の方も Docker で uchiwa にポータビリティを持たせたかったのかもしれません。 早速 Fork して… Dockerfile を作成 以下のような Dockerfile を作成してみました。 FROM centos RUN rpm --import http://ftp.riken.jp/Linux/fedo

2016年12月20日からスタートしたMBS（毎日放送）の有料動画配信サービス『MBS動画イズム444』にて、サーバーレス・アーキテクチャ（AWS Lambda）が全面採用されたという事例は、世界を見渡しても類をみない、大変優れた設計であると話題になりました。 でもね、重要なことは「AWS Lambdaを使って構築した」ことではないんです！ 『MBS動画イズム444』は、次々と新しい動画コンテンツが増えていますし、有料会員も猛スピードで増えていると伺っています。そうなると、このサービスの安定運用こそが、もっとも重要なことなのです。 そこで、この記事では「AWS Lambda」で構成されるシステムの運用をcloudpackならこうやります！というのをご紹介いたします。 サーバーレス・アーキテクチャのシステム運用はどう考えるべきか？ 『MBS動画イズム444』のシステム構成は、実に複雑です。

tl;dr 最新 Amazon Linux AMI の情報を返す Lambda Function を作ったけど死ぬほど遅かったので、その情報を S3 に置くことにして、さらに全リージョン分その処理を行う Function も作った。 ソースはここ。 どうぞご利用ください $ curl https://s3.amazonaws.com/latest-ami/.json S3 じゃねーか！ はい。要は S3 に JSON を置いてるだけです。その JSON を自動で更新する仕組みを作ったという話です。理由は後述します。 これを書いてる時点で情報が取得できるリージョンは ヴァージニア カリフォルニア オレゴン アイルランド フランクフルト サンパウロ 東京 ソウル シンガポール シドニー ムンバイ です。 $ curl -s https://s3.amazonaws.com/latest-ami

Nginx 初心者のかっぱ（@inokara）です。 追記（1） ngx_mruby 作者の @matsumotory さんに以下オンようなコメントを頂きました！ 有難うございます！ 追記（2） 連載（笑）にしようと思いますのでタイトルに数字つけました。 はじめに Nginx は設定に if が使えたりとデブオプスのココロを擽る Web サーバーだと思っていますが、細かい制御をしたいなと思った時に設定ファイルをグリグリ書くのはどうもなあと思っていたら mruby でイジれる ngx_mruby があるではないですか！ しかも、事例が既に載っているではないですか！ Dockerとmrubyで迅速かつ容易にnginxとapacheの柔軟なリバースプロキシ構成を構築する ということで、自分も試してみたいと思います。（以下、作業中の内容も含まれますのでご注意ください） やりたいこと リバースプロキ

大量アクセスなどの影響でログファイルが巨大であったりすると、日々のlogrotateが重くなります。 対象ディレクトリ以下に大量のファイルがある場合も時間がかかることがありますが、その場合はローテションの 世代数を減らしたり、対象ディレクトリから定期的に退避すれば済むため、ネックになるのは主に圧縮によるもの だと思います。 デフォルトではgzipが利用されますが、別の圧縮プログラムを利用することもできます。 圧縮プログラムの選定ですが、基本的に圧縮率の高いプログラムは時間がかかりますし、高速なものは圧縮率が 低いものが一般的ですが、例外があります。 gzipなどはシングルコアしか使用しませんが、マルチコアで分散処理する圧縮プログラムだとおなじ圧縮 フォーマットでも格段に速くなります。 今回は、その例としてpigzを利用してみます。 pigzは、gzipフォーマットの圧縮をマルチコアで行う高