サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大谷翔平
sil.hatenablog.com
CRIUによるプロセスのリストアには複数のcapabilityが必要であり、コンテナ内部で行うためには--privileged相当で起動された特権コンテナでなければいけません。例えば、TCP connection repairにCAP_NET_ADMINが必要なのは明らかですが、もっと単純なプロセスであれば非特権コンテナでもリストアできるのでは...?と考えたのが事の始まりです。 背景 仕事で面倒を見ているRailsアプリの起動が遅いという問題がありました。起動が遅いとさまざまな弊害があるのですが、その一つにオートスケールが間に合わないというのがあります。 AWS FargeteやGoogle Cloud Runといった現代的なサーバーレスソリューションでは、ひとつひとつのコンピューティングリソースは小さく、リクエスト数の増加に応じて水平にスケールします。このようなアーキテクチャでは、コン
最近、個人的にsigstoreのKeyless Signingがアツいです。以下のブログを読みました。 これらの記事は主にコンテナイメージの署名について解説しているのですが、sigstoreはバイナリの署名にも使えます。以前から、複数メンテナ体制で秘密鍵をどう共有しよう?とか、公開鍵の安全な配布方法って無くない?と考えていたので、渡りに船です。 チームでひとつの鍵を保守したい場合とかどうやってるんだろ、みんなに主キー配るんかな、まぁそりゃそうか...— wata (@wata727_) 2021年5月1日 リリースバイナリの署名に使った鍵をキーサーバーで公開してたら、今それ信用できんのでリポジトリに公開鍵入れてくれという話が来ていた、もう何も信用できないhttps://t.co/2g5diZxGIM— wata (@wata727_) 2019年12月24日 早速、採用に向けて色々調べてい
CVE-2019-5736を覚えていますか?今年の2月に見つかったrunc(Dockerがデフォルトで利用しているコンテナのランタイム)の脆弱性で、ホストのruncバイナリを好き勝手にコンテナ内部から書き換えることができるというものです。 脆弱性の仕組みに興味があったので調べたところ、コンテナを攻撃する方法というのは他にもいろいろあって、runcは頑張ってそれを塞いでいるようです。これまとめると面白いかも、と思ったので以下のようなおもちゃを作りました。 Drofuneは簡単なコンテナランタイムです。drofune runとかdrofune execなどでコンテナを起動したり、入ったりすることができます、といえば想像がつくでしょうか。 これだけでは何も面白くないので、Drofuneはわざと安全でない実装になっています。なので、今回発見されたCVE-2019-5736を利用した攻撃も成立します
RuboCopのIssueを眺めていると、いろいろな人のRubyの考え方に触れることができて面白い。例えば、多くのRubyistにとってprivateなメソッドを宣言したいときには、以下のような書き方をすると思う。 class Cat def meow puts "Meow!" end private def bowwow puts "Bowwow!" end def cock_a_doodle_doo puts "cock-a-doodle-doo" end end privateの後にインデントするとかしないとか、微妙な差異こそあれど、大体こんな感じ。でも、これをよくないと考える人もいる。ではどうするのかというと、以下のようにインラインでアクセス修飾子を書くべきだという主張。 class Cat def meow puts "Meow!" end private def bowwow
普段、Rubyを書いていると、Goでaws-sdkを扱う際にAPIの呼び出しをモック/スタブするのが意外と大変で苦労する。よくGoのテストのプラクティスとして、スタブしたい関数をグローバル変数に入れておいて、テスト時にすり替えるというのがあるが、もうちょっとなんとかならないかと思ったりする。 以前、gomockを使った、いい感じのaws-sdk-goのモック/スタブ方法を見かけて、それ以来、実践しているのだけれど、残念なことにその元記事が消えてしまった(たぶん)。せっかくなので、この方法論をまとめておくことにした。 gomockとは何か これがとてもよくまとまっているので、これを読めばいいと思う。 流石に丸投げはアレなので、簡単に説明すると、interfaceを元にモック用のGoのコードを生成してくれる。aws-sdk-goはこういったテストのために各APIのinterfaceを公開してい
最近、RuboCopへのパッチを投げるようにしているのですが、なんか良さそうなバグは無いかなとissueを漁っていたところ、こんなissueを見つけました。 このissue自体は単なるfalse positiveなので、まぁ対応すれば良いのですが... こっちがその問題のCopが追加されたプルリクエスト。 このCopが教えてくれることは、状況によっては :inverse_of を明示的に指定しないと、意図した挙動をしないことがあるので、その場合にはちゃんと :inverse_of を書きなさいね、ということです。ただ、1個目のissueのコメントで「Railsガイドには :through とか :polymorphic を指定していると、:inverse_of は効かないって書いてあるけど、それでも指定しないとダメなの?」と言っている人もいます。 :inverse_of については、Rai
RailsのECS移行事例なんて既に山ほどあるので、特に書くつもりは無かったのですが、実際にやってみると 時代が進んで、より便利なものが出てきている デプロイどうするのよ、となったときに各自が最強のECSデプロイツールを作っていて、参考にならない といった体験をしたので、最近やったECS移行の話を書くことにしました。 社内Qiitaに書いたポエムです pic.twitter.com/yDlWGhhkF1— wata (@wata727_) 2017年8月31日 もちろん、この記事も古くなると何の役にも立たないと思うので、古くなったら、みなさん頑張って調べてください。 ECS移行で考えるべきこと まず前提として、移行対象はシンプルなRailsアプリで、WebサーバとWorkerからなります。デプロイはCapistranoなどのいわゆる「Push型」で行っていたものとします。Railsに限定し
最近、AWSからALBというビックなアップデートが発表されました。 【新発表】AWS アプリケーションロードバランサー | Amazon Web Services ブログ ALBは従来のELBと比べてコンテントベースルーティング、優先度の設定、HTTP/2、WebSocketの対応など、さまざまな変更点を含みます。従来のELBをClassic Load Balancerと呼んでいることからも、今後はこちらへの移行を推進していくものと思われます。 今回のアップデートはかなり衝撃的で、幅広いユースケースが見込めることから、Terraformも早々に対応しています。 Terraform 0.7.1 released! https://t.co/ZenWICp9w9 AWS ALB support along with dozens of other improvements and bug fi
以前から、インフラそのものの構成管理にはTerraformを利用しています。主にAWSのリソース管理に使っていて、Terraform自体はaws-sdkのラッパーみたいな感じなのですが、宣言的に構築できるので、複製が容易であったり、変更に必要な操作(modify系のAPI実行)を意識せずに、こうなってほしい、を記述することで、現状から必要な操作を計算してAPIを叩いてくれたりというメリットがあります。 で、実際に変更したい状態にするために、Terraformが何を行なうか、については「terraform plan」というコマンドで確認できるようになっています。まぁdry-runみたいなものなのですが、あくまでもTerraformの実行計画上のdry-runであって、aws-sdkのdry-runではないというのが結構困りポイントです。 具体的には、Terraform上で別のリソースの値を参
タイトルの通り、デプロイ後にAMIを作ってAMIの世代管理もできるCapistrano3向けのプラグインを作りました。 要件としては意外とありそうなのに、(自分で調べた限り)gemがなかったので、作ったという経緯です。AMIを作るだけならば、適当にaws-sdkをrequireしてタスクを一から書いてもよさそうですが、世代管理まで自前で書くのは面倒かと思う(というか自分で書いてみて面倒だった)ので、とりあえずバックアップとしてAMIは定期的に取得したいよねっていうときに使ってもらえるといいんじゃないかと思います。 使い方 基本的にREADMEに書いてある通りですが、日本語でも書いておきます。 インストール https://rubygems.orgで公開しているので、いつもの通りにインストールできます。 $ gem install capistrano-ami もちろん、Gemfileでも使
先週、Rails寺子屋に参加させていただきまして、いまさらながらRailsデビューを果たしました。もともとバックエンドにはFuelPHPを使っていたので、未だにRuby独自の記法に四苦八苦しながらも、Scaffoldの強力さに感動を覚えている次第です。お恥ずかしながら、FuelPHP使っていたときにはmigrationとか使うことはありませんでした・・・ Railsを触り始めて「とりあえず頭の中にある作りたいものを、最小構成で作ってみよう」と思いたち、複数のグループがあって、そのグループに属するユーザが複数いて・・・みたいなのを作り始めました。しかし、Resourceをネストさせる辺りで詰まったのでメモ。 やりたいこと 上でも少し書いていますが、グループウェアツールみたいなイメージで、複数のグループと、その下に複数のユーザを作成できるようなサービスを開発するイメージです。 RailsにはS
入社エントリです。正直ちょっと書くのに憧れてました。 標題の通り、株式会社アクトキャットに入社しました。 概要 前職を3月末日付けで退職し、4月頭からお世話になっています。 実際には有給消化の都合上、仕事は3月頭までしかしていなくて、残りの期間は東京へ引っ越しをしつつ、初の一人暮らしで四苦八苦したり、社会人ではなかなか経験できない長い春休みを満喫させてもらいました。 長い休みが確保できたので、せっかくなので何か開発しよう!と考えていましたが、ネットが長期間繋がらないという問題もあって、ほぼ引きこもるか生活用品の購入をしたりしてました。春先のタイミングなんで、ネット開通の手続きの時間がめちゃくちゃかかるんですね・・・知らなかった。 何処に行くにも人だらけで田舎者としては人通りの多い場所は避けたいと思う次第です。 きっかけ ちょうど今年の4月で中学とか高専時代の同級生が大学を卒業して(高専時代
1日に一度だけ、1時間に一度だけ、あるタイミングで処理を走らせたいというニーズは常に存在します。昔から多くのエンジニアはそういった要望に対して、サーバを用意して、crontabに独自の魔法を書くことで対応していました。 時は現代、インフラといえばAWS、GCP、Azure... サーバを使い捨て可能なリソースとして扱えることのメリットに人々は熱狂しました。また、AWSが掲げた思想、"Design for Failure"(障害の為の設計)は多くのエンジニアに受け入れられました。 ここで改めて定刻に処理を行う方法について見てみると、やっぱりインスタンスを立ててcrontabを利用する方法が使われているようです。これは決して可用性の高い実装ではありません。なんとかしなくてはいけません。 以前、同様の問題に対して、DataPipelineを用いたアプローチを検討しましたが、スケジュール処理をDa
Infrastructure as codeの思想に感動し、AWSを使い始めて早1年になりますが、なんだかんだで最近はコードを書いてばかりでAWSを触っていませんでした。貴重な無料期間も終了し、非常にもったいないことをしたなと反省中です。 さて気を取り直して、ついに先日 EC2 Container Registry (ECR)がアナウンスされましたね! まだUSリージョンのみの公開で、相変わらず東京リージョンはもう少しかかりそうですが、これでDockerイメージの管理までAWS上で行えるようになるわけです。 ところで、インフラ構築の自動化といえば、Elastic BeanstalkやOpsWorks、CloudFormationなどなどAWS上でもサービスが乱立しており、少し外に目を向ければ、Chef、Puppet、Ansible、Terraformなどなど、もう困っちゃうぐらい選択肢にあ
前回の記事ではDockerとECSを使ったAWS上でのInfrastructure as codeについて言及しましたが、サーバリソースの構成管理についてはAWSのマネージメントコンソールから手動で行わないといけなかったり、コンテナを用いたアプリケーション構成を強制され、従来の単純なインスタンス構成ができないという問題点がありました。前回の記事はこちら。 後者については、今後コンテナを活用したインフラ構成が普通になっていくことで許容されていくかもしれませんが、普通にインスタンスを立ててインフラを構築している方にとってはInfrastructure as codeをやりたいためにコンテナを前提としたサーバ構成に変更しなくてはいけないなんて、正直気が進まないと思います。 そこで本記事では、今インフラ界隈で非常に強い影響力を持っているHashicorpのプロダクト、PackerとTerrafor
最近仕事でFuelPHPを使う機会を得たのですが、FuelPHPのデフォルトで用意されているバリデーションルールで少しハマった部分があったため、戒めのためにまとめておきます。 意外とググッても情報が出てこない部分があって、公式ドキュメントはそれなりに充実しているものの、細かな仕様までは書かれていません。最終的にはコアのコードを読むのが一番だと気づいてようやくバリデーションルールの仕様がわかってきたのですが、やっぱり困ったらコアのコードを読む気持ちを持とうよという話です。 前提条件 使用するバージョンは以下の通り。 名前 バージョン PHP 5.5 FuelPHP 1.7 発端になったバリデーション 今回の発端になったのは以下のような名前や年齢を受け取り、検証するフォームです。 コードはこんな感じ app/classes/controller/validation.php <?php cla
最近RailsのScaffoldから色々開発するのにハマっていて、WEBRickで動作確認しながら、ちょこちょこ開発していました。 そろそろ公開環境へのデプロイ自動化を考えないとなーとなって、せっかくなので今までやっていた単純なAnsibleを使用した形ではなく、デプロイ支援ツールであるCapistranoを使ってローカルマシンからデプロイする手順を自動化してみました。 ちなみに、今までまとめてきたAnsibleを使った形式は以下の記事にあります。 やりたいこと Mac OS Xのローカルマシンでrails newして生成したプロジェクトを、ローカルからcap production deployするだけで、AWS上のEC2インスタンスにデプロイします。 AWS上の環境はNginxをプロキシとして使って、Unicornをアプリケーションサーバとして採用する王道構成です。NginxとUnico
過去の記事からもわかっていただけるかと思うのですが、AWSやらFuelPHPやら、どちらかというとバックエンドの仕組みやインフラの仕組み作りを楽しいんですよね。 そんな感じで色々自分なりにやりつつも「あー、やっぱり自作アプリぐらい作っておきたいなぁ」と思い、FuelPHPでちまちま書いていたのですが、全然続かないわけですよ。 なぜか。それは成果物の見た目がかっこよくないからです。いくら頑張ってきれいなコードを書いたところで、できたアプリがダサいようでは、機能拡張もやる気になりませんよね。 というわけで、フロントエンド初心者丸出しの私がちょいとググって良さそうだったYeomanを使って、AngularJSを使ってAPIレスポンスのJSONを取得、非同期に画面を更新するというバックエンドとの連携部分をサクッと実装してみましたので備忘録として残しておきます。 Yeomanとは Yeomanとはフ
最近、時間がないことを理由に開発環境構築だけで、私的にプログラムを全然書いていないのですが、忙しさを理由に平日のコーディングをサボってはいけないなと思えてきました。では、仕事を終えてコードを書こうと決心すると、 AWSマネージメントコンソールにログイン Authyでワンタイムパスワードを確認して入力 EC2メニューにアクセスして、インスタンスを起動 ステータスチェックを終えたらパブリックDNSを確認 Route53メニューにアクセスして、対象レコードのCNAMEをパブリックDNSで更新 という流れになりますが、まぁ面倒臭い! これでは平日に帰ってきてからコード書く気力も失ってしまいます。そこで、今回はこの手順をAWS CLIを使うことで、コマンド一発で済ませるようにしてみます。 使用しているバージョン 今回はクライアントPCからAWS上のインスタンスに操作をします。 各バージョンは以下の通
最近コードを書いてはいるものの、なかなかブログにできるネタがないため、またブログを書くとなれば結局AWSとかインフラ側の話になっちゃうんですね。 さてさて、今回はCDPで問題になりがちなバッチ処理、ジョブスケジューリングです。単純に実現するならばインスタンスを立ててcronで実行する、という形になりますが、実行保証もないし、インスタンス落ちたら終わりだし、AWSのベストプラクティス的にはありえないです。 ではどうするのかといえば、SQSやSWFで冗長性を確保することですが、どちらも実装するにはちょっと面倒臭い。単純にある時間になったらデータを取得してきて、S3に投げるだけのバッチ処理を実装するのに、そんな苦労はしたくないし・・・ と思っていたとき、思わぬサービスを見落としていました。そう、AWS Data Pipelineです。本記事ではAWS Data Pipelineを使って日次バッチ
最近興味があり、Herokuを触り始めたのですが、今年の新人研修でクラウド関係の話を非エンジニア含めた場で話させてもらえる機会があるので、AWSに限らず、Herokuの話をしようかなと思っています。 個人的にはクラウドといえば、AWSのようなIaaSなのですが(GCPの方はすいません)非エンジニアの方にAWSのメリットを語るためには、いかにハードウェアを扱うことが面倒臭いか、インフラを自前で管理することがトラブルに繋がるかという部分を体感してもらえないといけないなぁと思いまして、そうなってしまうと、手っ取り早くクラウドの面白さ、便利さを体感するならばPaaSが一番だろうと考えました。 特に、黒い画面を見ることに抵抗がある人でも簡潔にやる方法として、HerokuのDropbox連携が一番簡単にできそうだったので、事前に手順を整理しておきます。 Herokuとは www.heroku.com
フレームワークというものを学びはじめてざっと5ヶ月くらいになるんですが、FuelPHPに限らず、CakePHPやRuby on RailsなどのWebアプリケーションフレームでは必ず登場するキーワード「MVC」についてちょっと理解が浅かったので、改めて色々調べてみました。 ようやく自分なりに納得のいく答えができたのでメモとしてまとめておきます。なお、具体的なプラクティスに関する知識は皆無な身の上ですので、「俺はこうやったほうが好き」といったご意見は大歓迎です。ぜひコメントでもTwitterでもいいので一言いただけばと思います。 MVCとは MVCとはModel, View, Controllerの頭文字をとった言葉で、アプリケーション開発における役割の分離を実現するためのソフトウェアアーキテクチャです。簡単に言ってしまうと Modelはデータ加工などビジネスロジックを司るコンポーネント V
ありがたいことに、以前のJenkins自動デプロイ記事がそれなりに多くの反応をいただきまして、冷静に見直してみたのですが、ちょっとデプロイ処理が雑だなと。 最近ではデプロイをやるにも、Capistranoやfabricなどのツールがあり、多様化するデプロイ要件に柔軟に対応できるような工夫が施されています。これらのツールを用いることで、シェルスクリプトで記述されたぐちゃぐちゃなオレオレデプロイを回避できたり、デプロイ失敗時のロールバックなどがしやすくなるメリットがあります。 現在開発しているアプリでは、git pullだけでデプロイできるようにしてあるので、前回の記事のようにJenkinsのジョブにシェルスクリプト直書きでもいいのですが、 デプロイ先の変更やスケールアウトに対応しにくい 認証鍵の場所をコマンドで直書きするのが、個人的にちょっと抵抗ある 書き方がスマートじゃない ←重要 という
最近AWSが楽しすぎて1年契約した某VPSの方を放置しっぱなしです。よくないですね。 諸事情により、今年中にAWSのソリューションアーキテクトを受ける事にしたので、しばらくAWSしか触らない生活が続きそうです。本業のプログラミングが進まない進まない。そろそろフレームワークの選定とかしたいんですけどね。 前回まででEC2を直接立ち上げて、Webサーバとして運用する話をしましたが、EC2を含むいろいろなAWS便利サービスを包括的に扱えるElastic BeanstalkというサービスがAWSでは提供されているので、早速触ってみようと思います。 Elastic Beanstalkとは Elastic Beanstalkとは、AWSにて提供されているアプリケーションを統合管理することができるプラットフォームです。と、言ってもピンとこないですよね。 AWSではElastic Load Balance
前回の記事ではFuelPHPのバージョン管理をやりまして、ソースコード管理のモデルがとりあえずできたかなという感じです。ただ、gitのバージョン管理をどんなブランチモデルでやろうかなと考えていたところだったので、今回固めてきました。 gitは非常に奥が深いですね。まだ全然把握しきれてはいないと思いますが、とりあえず雰囲気はつかめたと思うので、今後こんな感じのブランチモデルで運用していこーって概要と、こんなケースにはこうやってSourceTreeを操作するよって内容を備忘録的にまとめておきます。 あとで対応できないケースが増えて、モデルの見直しが必要になることもあるかもしれませんが、今はこれでいく!ということで・・・ 今後運用するブランチモデル 早速ですが、運用するブランチモデルについて概要を書いておきます。 基本的に個人開発なのでブランチ運用する必要性すらあるのかと思うかもしれませんが、今
# 2015年12月アップデートしました。本記事の元ネタは2014年11月に書かれたものです。 やはり時代は話題のAWS、ということで。クラウド新時代のIaaSとして、どんどん成長を続けるAWS。クレジットカード登録必須なのが抵抗感を煽っていましたが、やらざるを得ない状況になりつつあるので、とうとう登録しちゃいました。 正直、この手の新しいプラットフォームは流行が廃れたらもう使わなくなる技術だと思っていたわけですが、想像以上に利便性が高く、関連知識がないとWebサービスの構築もできない時代が来る気がしたので、先行投資ということで断腸の思いでサービス登録しました。 ありきたりではありますが、メモ書きとして、Webサーバ構築までの流れをメモ。 Amazon Web Services (AWS)とは? AWS、正式名称はAmazon Web Services。 ここで語らずとも、そこら中で紹介さ
以前までの記事でデプロイ、テストの自動化ができたわけですから、これで後はゴリゴリコーディングするだけ、ということで、Route 53でドメイン購入までしたわけですが、いまさらになってGitHubをリポジトリホストに使うのはちょっと厳しいなと。 できればAWSのVPC内にGitサーバ立てて、プライベートなリポジトリホストを使用するつもりだったのですが、そのためにインスタンス立ち上げるのはもったいない、という理由からGitHubを採用していました。しかし、Jenkinsサーバを立てている現状、Jenkinsサーバにリポジトリホストとしての役割を兼任させればいいじゃんという結論に。 HTTP経由でリポジトリを参照するようにしようかなと思っていたところ、社内でGitBucketというGitHubのクローンでサーバ立てたという話を聞き、すごく良さそうだったので試してみることにしました。 GitBuc
今回の記事もFuelPHPです。以前からコードを書いてはいましたが、プログラミングするなら、今の時代はgitでバージョン管理したいですよね。 インフラはみんなだいすきAWSなので、gitサーバを立てるのは難しくないけど、いちいちインスタンス立ち上げるのももったいない、別に隠すものでもないし、Github使おう。 というか、FuelPHP自体がgitでバージョン管理されてるの?え?じゃあ管理しにくくね?え?モデル、コントローラー、ビュー別にそれぞれリポジトリ作るの?え?え? ・・・このように、フレームワークのプロジェクトのバージョン管理って結構面倒くさいらしいんですが、色々ググって、とりあえずこれでいいか、というところまで辿りつけたので記事にまとめておきます。 今回のゴール 今回の目的は、もちろんFuelPHPのプロジェクトをGithubでバージョン管理することにあるのですが、バージョン管理
Jenkins、いいですよね。オペレーションの自動化には美があります。前回の記事ではGitによるデプロイ自動化を行いましたが、その時点で既にユニットテストの自動化は想定していたので、今回はそれを実現してみます。 これによって、機能を実装してプッシュする度に自動でデプロイされ、その過程でテストが自動で行われるので、特に通知がなければ動作が保証されるようになります。実際に本番環境への適用の際には、もう少ししっかりテストをする必要があるのかもしれませんが、開発環境レベルではテストを意識的に実施せずとも気兼ねなく開発を進めることができます。 ユニットテストにはおなじみのPHPUnitを使います。なお、前回のJenkins導入やデプロイ自動化の話はこちらの記事でまとめてありますのでよろしければどうぞ。 ユニットテストとテスト自動化 従来、プログラムのテストはミスの許されない商用プロダクトでは欠かせな
次のページ
このページを最初にブックマークしてみませんか?
『sometimes I laugh』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く