イントロ 今更だけどハマったので書いておく。 I, [2017-11-15T17:45:38.423986 #7537] INFO -- : executing ["/var/www/app/releases/20171115083608/vendor/bundle/ruby/2.4.0/bin/unicorn", "-c", "/var/www/ser val/current/config/unicorn.rb", "-E", "production", "-D", {15=>#<Kgio::UNIXServer:fd 15>}] (in /var/www/app/releases/20171115084509) I, [2017-11-15T17:45:38.424276 #7537] INFO -- : [before_exec] path: /var/www/app/current

ln は引数１つだけで実行できる ln に引数を１つだけ与えて実行すると，カレントディレクトリに指定したパスへのリンクを作成します． たしかに，どのファイルへのリンクを作るかを指定しなければリンクは作れないので納得できます． ~/work% ls -l 合計 0 ~/work% ln -s /bin/sh ~/work% ls -l 合計 0 lrwxrwxrwx 1 tn tn 7 6月 7 12:10 sh -> /bin/sh* lnコマンドを使うときの心の中 lnには少なくとも１つの引数が必要であることを知ってから，次のような順番で考えてコマンドを入力するようになったので引数の順番を間違わなくなりました． 「シンボリックリンクを作ろう」

最近Capistranoを導入しました． 一般的なRailsのプロジェクトにCapistranoを組み込むのは，このあたりを参考にすると割と楽にいける． morizyun.github.io qiita.com ただ，これに合わせて重要になってくるものがあって，どうにもこれだけではunicornのリスタートがうまくいかなかったので，書き残しておく． unicornのoldプロセスが死んでくれない 今回，capistrano3-unicornというgemを使用した． まぁ内容的にはそんなに難しいことはなく，unicornにUSR2シグナルを送るだけである． tablexi/capistrano3-unicorn · GitHub だけど死んでくれない． これは，unicornのconfigの書き方に寄るところが大きい． まずcapistrano側でunicornの設定ファイルを置く 上記のc

業務のプロダクトにおいて、これまでredisはAWSのElastiCacheを使用していたのですが、色々と訳ありで一旦EC2インスタンス内に直接redisをインストールしてしまおうという話になったため対応しました。 やること 現状としては、webサーバーやDBサーバーなどの複数のサーバーからElastiCacheのエンドポイントを参照している形になりますが、 今回は1つのインスタンスにのみredisをインストールして、他のインスタンスからもアクセスできるようにしたいので、 インスタンス1にredisをインストール インスタンス1に固定IPの割当 インスタンス1に他のインスタンスから通信ができるようssh鍵を登録 あたりの工程が必要になるかなと思います。 redisをインストール まずは現状のElastiCacheのバージョンを確認 $ redis-server -v 3.2.11 これと同

0. 導入 Railsでアプリケーションを作成しデプロイしました。しかし、Nginxの設定が原因でPOST Requestを行ったタイミングでエラーが発生してしまいました。どのようにエラーを解消したのかということをまとめます。 1. 概要 1.1. 構成 SakuraのVPSを借りてCentOS7系をインストールしています。 NginxをReverse Proxyとして動作させ、HTTPS通信を終端化し、リクエストをアップストリームサーバ(puma)に転送します。 pumaとRailsアプリはRack1を介してrequestとresponseをやりとりします。 1.2. 問題点 少し長目の記事なので最初にどこが問題であったのか書いておきます。 今回はNginxをReverseProxyとした際に、アップストリームサーバに必要なHTTPヘッダーを渡せていなかったことが問題でした。 2. エラ

SREの深尾です。kurashiru [クラシル] のインフラを担当しています。 タイトルのとおり、クラシルのwebサイトではRailsを使っており、１サーバあたり10,000人程度のアクセスに耐えることができます。実際には余裕を持たせて5,000人/サーバを目安にスケールさせており、TV CMをガンガンやったり、国内外のTV番組で特集されたり、芸能人にSNSで拡散されても動じませんが、実は過去に１度だけWebサイトがダウンしてしまったことがあります。それは2017年3月11日にSmaSTATION!!というTV番組でクラシルが取り上げられた時のことでした。 以下はその時のリクエスト数を表すグラフです。ダウンしてしまったので計測できなかったユーザの数字は含まれませんがそれでもアクセス数は１分で数万人を超えていました。 それまで、Webサイトの負荷対策はあまり行っておらず、２台のWebサーバ

導入 Rails(に限らずRuby)で作ったWebアプリケーションを運用する場合、次のような構成を取ることが一般的かと。 Internet <-外と中の壁-> nginx <--> Unicorn <--> Rails この際、nginx/Unicornのワーカー数の設定をどうするかで迷ったことはないでしょうか。 nginxはイベント駆動型なため、基本的にはワーカー数 > CPU数にしても意味がありません。自動設定ではCPU数と同じになりますが、わざわざ変更する意味もないでしょう。 一方Unicornはシンプルなマルチプロセスモデルであるため、ワーカー数の設定が重要な意味を持ちます。 ワーカー数の設定 もしアプリケーションが純粋にCPUだけを使うものであった場合は、nginxと同様にワーカー数をCPU数より増やしても意味がありません。しかし実際のアプリケーションはDBを読んだり外部APIに

もくじ WEB/APサーバが一体化された構成 WEB/APサーバが分離された構成(WEB:AP = 1:1) WEB/APサーバが分離された構成(WEB:AP = 1:多) WEB/APサーバが分離された構成(共有ディレクトリ有り) UNIXドメインソケット利用時の注意点 1. WEB/APサーバが一体化された構成 WEB(Nginx)とAP(Rails)を1台のサーバ内に収める構成です。 NginxとRailsの連携にはUNIXドメインソケットを利用します。 【Nginx ポケットリファレンスより抜粋】 UNIXドメインソケットのでの接続は同一サーバ内に制限されますが、TCP接続と比べて接続時のオーバーヘッドが少ないので、細かい大量のアクセスを処理する際に負荷の軽減を図ることができます。 UNIXドメインソケットを利用するために、pumaのコンフィグにsockファイルのパスを指定します。

エラー文の例 Rails6の新機能である、Action_textやActive_Storageを利用する際に、awsなどの認証情報をEDITOR=vi rails credentials:editで書き込んでいると思います。しかし、それだけだとローカルでは動作しますが本番環境では動きません。 ... /var/www/app-name/shared/bundle/ruby/2.6.0/gems/aws-sigv4-1.1.0/lib/aws-sigv4/signer.rb:612:in `extract_credentials_provider': Cannot load `Rails.config.active_storage.service`: (Aws::Sigv4::Errors::MissingCredentialsError) missing credentials, prov

Amazon Linux2にMySQL5.7の環境構築をしていきます。MySQL8のリポジトリに5.7も含まれているのに気づかず、随分と探し回ってしまいました。amazon-linux-extrasではmysqlはインストールできないのかな。 バージョン情報 Mac OS 10.11.6（El Capitan） Amazon Linux 2 AMI (HVM) mysqld Ver 5.7.22 for Linux on x86_64 (MySQL Community Server (GPL)) その他情報 Qiita:AWSのEC2で行うAmazon Linux2（MySQL5.7）環境構築 - Qiita 事前に用意しておく必要があるもの 接続先EC2のパブリックDNS 作業ユーザ（Amazon Linux2の場合デフォルトはec2-user） EC2からダウンロードした秘密鍵（デフォ

Capistrano 2 系の記事を今さら書くのも微妙だが、作業メモ。 3 系でも同じような感じで使えるはず。 概要 Capistrano 2 系で踏み台サーバを経由してデプロイする方法。 状況は下記。 ローカルマシン -> 踏み台サーバ -> テストサーバ jetglass.hatenablog.jp 前に書いた↑これ(~/.ssh/config)を利用すれば簡単に実現できた。 実現方法 ~/.ssh/config の設定 まずは ~/.ssh/config の設定をする。 なぜ設定するかというと、 cap コマンドを叩くユーザの ~/.ssh/config を有効にできるため。 # Mac(ローカルマシン)の ~/.ssh/config Host bastion # ホスト名(任意) User tsuyacchi # ユーザ名 HostName xxx.xxx.xxx.xxx # IP

踏み台サーバ経由で git する方法をメモしておく。 Linux でも同じ、.ssh/config を編集して踏み台サーバ経由（SSHトンネル）する方。 あくまで Mac（ローカルマシン）から、git コマンドを直接叩きたいときの設定。 踏み台サーバ上で作業する場合の設定ではない。 踏み台サーバ経由(SSHトンネル)する ~/.ssh/config の設定 前提条件 bastion（踏み台サーバ） tsuyacchi というユーザを追加済み 公開鍵・秘密鍵を設定/設置済み Mac(ローカルマシン)側には秘密鍵（~/.ssh/tsuyacchi_id_rsa） サーバ側には公開鍵（cat tsuyacchi_id.pub >> ~/.ssh/authorized_keys） git_repository（git サーバ） bastion からのアクセスのみ許可 gitolite を使っていて

リモートサーバにrailsアプリケーションをCapistranoでデプロイしようとしていました。 Capistranoによるデプロイの流れはザックリとこんな感じです。 自分の端末からcap production deploy を実行する。 デプロイ先のサーバにて、github上のプロジェクトのcloneリクエストが行われる。 githubからプロジェクトがデプロイ先サーバにcloneされる。 そうしたところ、2番目の手順でエラーが発生しました。 $ bundle exec cap production deploy …… 00:06 git:check 01 git ls-remote --heads git@github.com:quotto/HatenaBlog.git 01 Warning: Permanently added the RSA host key for IP addr

先日、アイビスのサーバの引っ越しがありました。引っ越しは毎度毎度大変です。データセンターに置いていたサーバ群ですが、大変なのでやりたくないですが、引っ越しをせざる負えない事情がありまして、データセンターからAWSへサーバ40台の引っ越しをしました。 AWSは、受託開発では経験があるものの自社サービスでは初めて。僕も大急ぎで勉強して、晴れてAWSデビューです。 システム開発は、企画、要件定義、設計、実装、試験、運用とありますが、どれも楽しいですね。ものづくり万歳！。今回は、ネットワークアーキテクチャのお話です。ネットワークアーキテクチャを考えるとき、拡張性はあるか？可用性はあるか？負荷に耐えられるか？運用しやすいか？コストを下げるにはどうするか？と色々考える必要があって楽しいですね。 AWSの話の前に、まずは一般的な三層モデルの解説から。 クライアント(Webブラウザまたはアプリ)からApa

今日は、3層アーキテクチャを使用する利点を共有するための最初のハンズオンAWSプロジェクトを作成します。3層アーキテクチャは、論理コンピューティングの3つの「層」または「層」で構成されるソフトウェアアーキテクチャの一種です。特定のタイプのクライアントサーバーシステムとしてアプリケーションで使用されることもあります。このインフラストラクチャは、ビジネスロジック、ユーザーインターフェイス、およびデータストレージレイヤーを標準化することにより、本番環境と開発環境に多くのメリットをもたらします。これにより、開発チームは、アプリケーションの特定の部分を他の部分とは独立して更新できるため、柔軟性が高まります。この追加された柔軟性により、開発チームはシステムの他の部分に影響を与えることなく独立した層を交換またはアップグレードできるため、全体的な市場投入までの時間を短縮し、開発サイクル時間を短縮できます。

設計サンプルで学ぶ、AWS構築の原則 - Webアプリ アーキテクチャのベストプラクティスを理解する AWS入門者に向け、同サービスのエキスパートである、クラスメソッドの八幡豊さんが、Webアプリケーション開発のためのAWS構築の基本を解説します。広範な領域をフォローするAWSですが、広範ゆえに、なにをどのように選ぶべきか……。こんなお悩みを持つ方はぜひご一読を。 クラウドコンピューティングサービス・Amazon Web Services（以下、AWS）は、数多くの高機能なクラウドサービスを簡単に利用できることから、多くの企業が導入しています。AWSの知識を身につけることは、いまやエンジニアにとっての必修科目です。 そのサービス範囲は広範にわたることから、「なにを」「どうやって」使うかのかが重要な知識になってきます。AWSの各サービスのポテンシャルを引き出すためには、それぞれの長所・短所を

中〜大規模サービスのインフラの様子を知りたいアプリケーションエンジニア向けに、もともとアプリケーションコードを書いていた視点から、個人的な体験をベースにはてなで大規模サービスのインフラを学んだ過程や学んだ内容の一部を紹介します。 Webアプリケーションのブラックボックス Webアプリケーションフレームワークの向こう側 なぜ複数のサーバが必要なのか 突然のWebサービス3層構成 リバースプロキシ アプリケーション データベース その他のコンポーネント キャッシュは麻薬 飛び道具としてのKVS/NoSQL 非同期処理 バッチ処理 Mackerelの場合 参考 まとめ Webアプリケーションのブラックボックス 今年もはてなインターンの時期が近づいてきた。 毎年ではないけど、はてなインターンでは「インフラ講義」というのをやっている。 今年はインフラ講義の講師としてアサインされたのでちょうど何を話そ