はてなブックマーク

Jenkinsが頻繁にdisk fullになる ビルドの破棄の設定などもしているんだけど、workspaceがすぐに肥大化する問題が起きていた。あるジョブのworkspace配下に@がついたディレクトリがたくさんできてしまっていることは分かっていたんだが、消してもたまに復活してしまうので困っていた。 どうやら並列化すると起きるみたい 特に情報がなかったんだけど、この辺のissue見てるとなんとなく並列化実行してるやつが怪しいなという気になれた。 Build creates new workspace@2 (and so on) when option concurrent builds NOT checked Workspace directory names mangled in multibranch pipeline さっきのスクショの例だと、8まで増えてるけど、これはこのslave

Proxy ProtocolはL4におけるx-forwarded-forみたいなもの 2010年ごろからあるみたいだったけどお恥ずかしながら知らずに生きてきた。 HTTPヘッダが覗けるロードバランサー（L7ロードバランサー）ならx-forwarded-forとかx-real-ipとかにIPを追記していくことでclientのIPアドレスを保持することができる。 HTTP通信以外のL4ロードバランサーの場合はそれができないので、Proxy Protocolというプロトコルを使ってclient ipを保持するという仕組み。 もとは、ロードバランサーのソフトウェアであるHAProxyが策定したものだが、それをAWSなど有名どころが採用したため標準的なものとして採用されている。 AWSのELBはどうなってたか AWSの場合は、ELBでHTTPリスナーにすれば自動的にL7ロードバランサーになっているの

今まではnginxでリダイレクトさせてた こんな感じでhttpでアクセスしてきたらhttpsにリダイレクトするっていうのをnginxの設定で書いてました。 if ($http_x_forwarded_proto != https) { return 301 https://$host$request_uri; } これで困るのは ALBからのhealth checkはhttpで来るので、health checkも301が返っちゃうということです。 で、例えばuser agentがELB-healthcheckerで、かつ、httpだったら301じゃなくて200返すとか書けばいいんですが、nginxでand条件のif文書くのは結構大変なのです。（プログラミング言語ではないのでそういうもの） こちらの記事を引用します。こんな感じになっちゃうイメージです。 Nginxで複数条件のIF文を書く方法

moduleの誤解 何もわかってなかった。 module使うと変数とかをscope化できるからいいなーって思ってたけど、resourceもscope化されるってことだった。 まぁ逆に言えば、module内にresource名は被らないように気をつける必要がないとも言えるけど。 terraform how to get another module resource みたいな感じでググってもそんなにでてこないから多分当たり前の概念過ぎるんだろうな。 他のmoduleのresource名を取得するには resource名から取ろうとしてもダメ 例えばこんなディレクトリ構成で、bastionの方でbase_networkで定義したvpcのidが欲しいみたいな場合。 ├── base_network │   ├── route_table.tf │   ├── subnet.tf │   └──

nginxの設定は難しい アプリケーションの開発してたエンジニアにとってnginxの設定をさっと書くのは結構難しいですよね（自分も含めて）。もう試しながらやるしかないと思うので、そんなときに気軽に試せるやり方を紹介。Dockerを使うので、Docker for Macはもちろんインストールしておいてくださいね。 適当にディレクトリ作る 雑にデスクトップにnginxみたいなディレクトリ作る。 mkdir ~/Desktop/nginx 公式のnginxのconfをパクる # nginx.confをパクる $ docker run -it nginx:alpine cat /etc/nginx/nginx.conf > ~/Desktop/nginx/nginx.conf # default.confをパクる $ docker run -it nginx:alpine cat /etc/ngi

今回、レビュアーとして関わらせてもらい、本を頂けたので感想書いていきます。 とにかく内容が充実していて実用的な本です 私自身、業務でもコンテナの運用をやっているのですが各章知らないことがたくさんありました。全部で400ページぐらいあって1人でこの量書くのどれだけ大変だったんだろうという感じです。共著ではないので本全体を通して流れが一貫してると感じました。 まずはDockerの歴史や意義から始まり、Dockerの操作、Dockerfileでイメージの作り方、docker-composeでコンテナ連携と順を追ってステップアップしていきます。 そして、Swarmでオーケストレーション、さらにSwarmで作ったやつをKubernetesでもやってみようの流れから、ローカルでやっていたものをGKEにデプロイして一通りKubernetesのことが体験できるようになってます。さらに、コンテナのロギングな

Cloud Native Deep Dive #1 事前にアンケートを提出してテーブルごとに分けれてグループディスカッションをする形式のmeetupでホワイトボードを使ってわいわい議論した。ツイートがこれしかできなかったｗ きました #deepcn // Check out this Meetup: Cloud Native Deep Dive #1 https://t.co/EjRljPvRCM #Meetup #東京都 @Meetupさんから— オオシママサト (@_mpon) 2018年6月25日 テーマ1. k8sのマニフェスト管理・デプロイについて グループでデプロイ方法をまず紹介しあう。内容はこんな感じ helm template + kubectl apply helm go template Spinnaker 個人的な気づきとしては、 マニフェストと一口に言っても、Web

k8s（頭のkとお尻のsを抜いてuberneteが8文字だから略してk8s、Internationalizationのi18nみたいな感じ)、の作者が基本的な機能を説明してくれる本です。正直公式documentと同じようなことが書いてある部分が多いっちゃ多いんですが、 日本語で読める ざっくりこんな機能があるんだー、こんなことができるんだーというのを知れる Kubernetesオブジェクトがなんでこういう単位で分かれてるのかという考えが知れる さっと読み終わる薄さがちょうどいい k8sやってみてるけど、まだまだ機能を使いこなしてないなという人には、へぇーこんなことできるんだと知るきっかけになる 例えばECSしか触ったことがない人が、えっこれってk8sならこれでできちゃうの！？みたいなことを知れる といったあたりでオススメだと思いました。 個人的には特に、14章の実用的なアプリケーションのデ

GKEで甘えてきました www.mpon.me 今まではGKE使っててIngress ControllerもGLBCを使ってなんか勝手にやってくれてるなみたいな感じで、 k8sを使う側そんなに気にしてなかったんですが、 EKSもくるということでAWSでやるにはどうすればいいだろうということを考え始めたというのが経緯です。 とりあえずIngressとは？ An Ingress is a collection of rules that allow inbound connections to reach the cluster services. とある通り、外部からのリクエストを各サービスに振り分けるルールを書くことができます。 なので、外部のクラウドプロバイダ上で立てる場合、Ingressを使った方が無駄なLBをたてずにすむので色々節約になります。 internet | [ Ingres

terraformでECSのclusterとserviceを作成するにあたって実際の運用を通して少し変わってきたのでまとめておく。 最初のterraformのmodule構成で起きた問題点 以前は、aws_ecs_clusterとaws_autoscaling_groupを同一moduleにおいていた。 問題その1: インスタンスの設定が無停止で変更できない これだと、何が問題かというと、autoscaling groupで立ち上がるインスタンスの設定はlaunch configurationというものに書くんだけどそれを書き換えたい場合に、既存のautoscaling groupが一時的に死んでしまい無停止で交換ができないようになってしまっていた。 clusterとautoscalingの関係を1:1と捉えてしまっていたのが問題で、1:Nということを分かっていれば無停止で構成変更ができる

Local Valuesがない世界😢 例えば、S3のバケットの名前をnameとenvっていう変数を使って"${var.name}-${var.env}"ってしたいとする。 resource "aws_s3_bucket" "b" { bucket = "${var.name}-${var.env}" } んで、例えば、このbucketの名前を他で使いたいときは、"${aws_s3_bucket.b.id}"ってやればいいんだけど、たまに循環参照が起きて使えないことがある。 例： s3_bucketのpolicyを指定したい -> policyにはs3_bucketから名前をいれたい みたいな場合。鶏が先か卵が先かみたいな感じになっちゃう。🐔 resource "aws_s3_bucket" "b" { bucket = "${var.name}-${var.env}" policy =

github.com インタラクティブにECS ServiceにデプロイされてるImageの一覧が見たいとき こんな感じで$ ecswalk servicesと打つと、jとkで選んだり、/を押してpecoみたいにinteractiveでfilteringして選ぶこともできます。 AWSのコンソールで見たときの情報と、Dockerのimageのタグも出してるから何をデプロイしてるかぱっと確認するのに便利。 こんな感じでサービス名、TaskDefinitionのバージョン、DockerのImage、Tag、DesiredCountとRunning Countを出しています。 ➜ ecswalk git:(master) ecswalk services ✔ prod-cluster Name TaskDefinition Image Tag Desired Running nginx ngin

入門三部作ラスト www.mpon.me www.mpon.me ここまでで、簡単にTerraformの機能をおおざっぱに説明してきました。 今回は、そこそこ現実に即したインフラを作るまでの流れを追いながら、徐々にリファクタリングしていくことで実践的な考え方を身につけていきましょう。 すごく簡略化した一般的なAWSの構成を題材にします 本番に完全に即してる訳ではないけども簡略化した構成を例として、terraformでの構築、リファクタリングの過程をやっていきます。 ディレクトリ構成などに焦点を当てていきたいので、セキュリティグループなど細かいことは省いています。また、あくまでも例なのでそのまま動くコードにはなっていません。 下図のような構成です。 ロードバランサーにEC2インスタンスがそれぞれ2つずつぶらさがってるような構成。各インスタンスにはnginxとRailsアプリケーションがいるよ

Terraform入門 #1の続きです。 Terraformを始めるのに一番の障壁 既存のインフラコードで試してみたいけどアクセスキーの準備とかアカウント申請が面倒だし、なんか壊しそうで怖い:scream: 自分でやるにしても、AWS契約しないと試せないんでしょと思って面倒になる:frowning2: もし自分のアカウントでやったときに高額請求されたらどうしよう:worried: この怖さがTerraformへの障壁をあげてしまってる気がします。少なくともぼくはそうでした。 簡単に試せるやつあるよ terraformはAWSのものじゃないと、Terraform入門 #1で言いましたが、他にも適用できるものが用意されてます。もちろん、GCPやAzureなどもそうですが、GitHubなどのサービスに対しても用意されてます。気になった人は、他にはどんなProviderがあるか確認してみましょう。

DNS-01方式 HTTPを利用して認証する場合に、IP制限や社内のみの通信などの制限をしている環境においてはLet's Encrypt側からの通信が届かないので認証できません。そこでDNSのTXTレコードで認証するDNS-01のタイプがあります。 こちらのサイトの説明がわかりやすかったです。 Let's EncryptのDNS-01を使用して無料のSSL証明書をWebサーバなしで取得する -- ぺけみさお 公式のcertbotが対応した 先ほどの記事執筆時点では以下のように書いてありましたが、 現在、Let’s Encrypt公式のletsencryptコマンドは、DNSによる認証をサポートしていません。 GitHubでプルリクエストはされていますが、まだマージされていません。 現在はマージされ使えるようになっていました！！ Dockerでcertbotを動かして生成する こういうとき便

人のコード見てわかった気になっていた 社内の他のインフラエンジニアが作ったnginxのDockerfileなどを見て、環境変数を読み込んでるっぽいらしい記述を横目で見ていたのでnginx.conf上で$HOGEとか書いておけばなんとなく環境変数って読めるんだろうって思ってました。 今回初めて一から作ることになってやっと気付きました。どうもゆとりエンジニアです。 まとめ ランタイムで読む方法とスタートする直前で変換する方法があるけど、後者が良さそう。 以下はこれにたどり着く流れの話です。 今のご時世、環境変数読みたいよね インスタンスにnginxインストールしてconf書き換えみたいな場合は、chefなどのプロビジョニングツールなどで変換すればよかったのです。 ただ、今のご時世、コンテナで動かしたいと思うのが正直なところ。コンテナだと一度作ってしまうと中身は基本書き換えられないし、書き換えて

scrapboxとは？ 知らない人もいるかもしれないので一応前置き。 scrapboxはなんか共同編集できるwikiみたいなサービス。 Gyazo作ったところが作ってる。 scrapbox.io scrapboxを使うとラバーダッキングができる ラバーダッキングとは 開発中にどうしようもなくハマってしまい動くと思ってるものが動かない。そんな時ありますよね。 例えばこんな会話 ぼく 「なんかコンパイルエラーがとれなくてちょっと見てもらってもいいですか？」 同僚 「いいですよ。」 ぼく 「○○な処理ができるように、こういう書き方をしてるんですが、コンパイルが通るはずが通らなくて。」 同僚 「ふむふむ。」 ぼく 「この処理を実行するには、△△というライブラリをimportしないといけないんですが、あっ！！」 同僚 「ん？」 ぼく 「importが抜けてました！！」 こうやって人に説明してると、頭

※ 追記 結構ちょこちょこブクマしてもらっているので意外と需要あるのかな。 もし、記事見て分からないところあったら Twitterなり気軽に質問してもらって大丈夫です！！ 社内でインフラエンジニア増やしたいなと思ってECSの概念を理解してもらおうと思って書いたやつです。 問題を間に挟みつつ理解の手助けになればいいなと思ってます。 今更ですがDockerとは？ 分かってる人はもううんざりかもしれませんが、一応復習。ECSの概念を理解するのに必要なコンテナを起動すると何が起きてるのかを再確認します。 普通の仮想サーバー 普通の仮想サーバーの場合は、sshでログインして、yumみたいなパッケージ管理システムでinstall、サービスをデーモンでバックグラウンドで起動しておくという感じですね。 Dockerの場合 Dockerはコンテナという単位で何かのプロセスを起動する仕組みです。基本的には、1

事の発端 Railsのlogrotateされたあとのファイルをどこに保存しようかと迷ったのがきっかけでした。 fluentdなどでS3に保存していくとか作るかーと思ってたんですが、社内のメンバーに相談してみたところAWSのCloudwatch Logsで簡単にできるよとのことで、調べてみたら本当に簡単便利安いだった。 インストールと設定 installはyum install awslogsでさらっとできる 設定もあんま深く考えなければこれだけでできる [/u/apps/log/production.log] datetime_format = %Y-%m-%dT%H:%M:%S file = /u/apps/log/production.log buffer_duration = 5000 log_stream_name = {hostname} initial_position = s

現象 普通Railsのアクセスログってproduction.logに出力されますが、出力されないことがあったという怪談の話です。 対応を1行でまとめると、Puma使うときはRails5からはRAILS_LOG_TO_STDOUTを設定しようということです。 👇 ここからは怪談の詳細です 原因1: logrotateの後処理の実行タイミングが悪かった 開発環境で確認してみたところ、logがログローテートされたあとファイル名の後ろにyyyy-mm-ddが付与されますが、 そのファイルに対して引きつづきログが出力されつづけていたのです🙀 で、既存のログローテートでこんな設定が書いてありました。 lastaction puma_pid=/path/to/puma.pid test -s $puma_pid && /usr/bin/kill -HUP -U root "$(cat $puma_p

○○○じゃダメなのか 単なるアプリケーションサーバー 秒間数百とか大量のデータを受け付ける場合に向いてない。 SQSじゃダメなのか キューイングが目的だけど、SQSは大量のデータを受け付けることは目的としてない。 SQSは命令をつっこむ、別のworkerがそれを取得して処理をキックするみたいな使い方に向いている。 参考: Amazon SQS と Kinesis はどう違うのか？～ユーザが求めるキュー(queue)の姿～｜AWSを使い倒せ | GiXo Ltd. ストリームデータ処理 こういう、大量にリクエストがきて、低レイテンシで処理をしなきゃいけない場合は、ストリームデータ処理というジャンルの話になってくる。 Googleが考えるストリームデータ処理とは？ IoT時代におけるストリームデータ処理と急成長の Apache Flink 分散ストリーム処理エンジンあれこれ ただし、単にストリ

前書き 人が書いたterraformのメンテぐらいは見よう見まねでやってるけど、一からやれと言われたらよく分からない。そう思ってた1年前ぐらいの自分を思い出しながら気軽に入門してもらうにはどうすればいいか考えてみました。 Terraformはこわくないしほんとに便利なので、その辺を感じ取ってもらえればと思います。 Terraformは何であって何でないのか、そしてなぜ必要なのか そもそも、学習するにあたってTerraformって最高便利というところが分かってないと、なんでやらなあかんねんとなりそうだなと思ったので、まずはなぜ必要かを説明していきます。 Terraformってインフラのコードで書くやつでしょ？ terraformはインフラのリソースをコードで書けて実際に作成まで行ってくれます。この辺はだいたい知ってると思います。 ただ、Terraformはchefとかansibleといったプ

Deisのpostgresをoff-clusterにする(Cloud SQLを利用) - まーぽんって誰がつけたの？やDeisのpostgresをoff-clusterにする(postgresql on GCEを利用) - まーぽんって誰がつけたの？でCloud SQLをdeisのdatabaseとしようともがいてたけど解決した話。 Cloud SQLはRDSと違う Cloud SQLはAWSでいうRDS的なやつ。ただちょっと違うのが、同じVPC的な論理的に同じネットワーク内に存在することができずに、別ネットワークになってしまう。 なので、GKE(Google Container Engine)のネットワークとCloud SQLはインターネットを経由しないとつながらないということになる。 GCPが用意してるCloud SQL接続方法 1. 接続してくるグローバルIPアドレスを許可する GK

背景 AWSでVPC作ったりしたことあるけど、GCPやったことないって人は色々違いに戸惑う アカウントの関係性、ネットワークの概念の違いなどを理解したのでまとめた AWSとGCPのアカウントの考え方の違い AWSの場合、ある人間に対して色々なAWSアカウントが付与される。 (人間) -> 個人で発行されたアカウント -> 会社で発行されたアカウント GCPの場合、ある人間は色々なプロジェクトというものに属することができる。 そして、その人間が使うアカウントはGmailとかで使ってるようなGoogleアカウントである。 (人間 with Googleアカウント) -> プロジェクト 会社のやつ -> プロジェクト 何の関係もない個人のやつ GCPの方が始めるのはすごく簡単な気がする。アカウント管理もGoogleアカウントさえやっときゃいいみたいな感じなので、Googleにロックインされる感は

こんな話は何年も前から語られてて答えも出てると思うけど、色々な意見を聞いて自分の考えが少しずつまとまってきたので残しておく。 聞いた意見 publicメソッドをテストすればprivateメソッドのテストも行われていることになる リフレクションやモックなど使えばテストできるかもしれないけどテストをされている状態のほうがマシなのでpublicにしてしまうという手もある そもそもテストしたいと思うということはそこに重要なロジックが入ってる privateなメソッドがテストできないことに悩むのはTDDじゃない証拠 変更後の状態をassertできない場合は確認するためのpublicメソッドを作る。例えアプリからは使われていなくてもテストからは利用してるのだから、テストも一つのアプリとして考えれば良い。 なんとなくまとめ こういう話を聞いてなんとなく、もっとテストのために楽してもいいんだなという気にな

どっちを採用するべき？ class Animal {} // or class Animal: NSObject {} こっちのにしておけばとりあえず間違いないとか、こっちを使うとこんな時に困るとかそういう指針が知りたい。 よさそうな回答 stackoverflow.com NSObjectを採用する時 Objective-Cのクラス メソッドを呼ぶ時にobjc_msgSend()を使ってる Objective-Cのランタイム時に取得する情報を使ってる時 Nativeクラスでいいとき Swift classes that are subclasses of NSObject: are Objective-C classes themselves use objc_msgSend() for calls to (most of) their methods provide Objective