AR ホームベーカリー

オイラのアウトプット用ホームベーカリー！

apache ユーザで git pull できるようにする

git memo

いわゆる RHEL 系で httpd インストールした以下の状態で、 apache:apache のまま github 運用するときどうするか、というやつ。

apache:x:48:48:Apache:/usr/share/httpd:/sbin/nologin

apache ユーザの設定

sudo -u apache でユーザ指定して git 各種コマンドで github と通信できるようにする。 鍵ファイルは DeployKey に登録するものとする。

作業手順

  • 鍵ファイル名は、仮に key.pem としています
  • 公開鍵 (key.pem.pub)も 600 にしてるけど、まあやらなくていいですね……
  • root ユーザで作業しています、ゆるして
[root@localhost ~]$ mkdir -p /usr/share/httpd/.ssh;cd $_
[root@localhost .ssh]$ ssh-keygen -t ecdsa -f key.pem -N ""
[root@localhost .ssh]$ vi config
[root@localhost .ssh]$ touch known_hosts
[root@localhost .ssh]$ chmod 600 key.pem;chmod 600 key.pem.pub
[root@localhost .ssh]$ chmod 644 config;chmod 644 known_hosts
[root@localhost .ssh]$ chown -R apache:apache /usr/share/httpd/.ssh/
config
Host github.com
  HostName github.com
  User git
  IdentityFile /usr/share/httpd/.ssh/key.pem
追記

運用環境のルールなどあると思いますが、鍵ファイルは生成時のタイムスタンプを入れておくと、Deploykey が失効するような環境ではある程度わかりやすい (要不要の判別) かもしれません。

そういう環境、結構あると思うんよ (引き継ぎなしの環境保守を引いたり)。

PREFIX に、環境を表すキーワードなど適当に入れてもらうとよりよさそう。

`date "+%Y%m%d%H%M%S"`-PREFIX_deploykey.pem

接続テスト

以下 apache ユーザで接続をテストします。

[root@localhost .ssh]$ sudo -u apache ssh -T git@github.com
Hi deploy-key! You've successfully authenticated, but GitHub does not provide shell access.

オッケーですね。

github 用の SSH 鍵とか DeployKey 用のアレそれを作る

git memo

いつものように DeployKey が失効した環境があったので、 ssh-keygen するなどしていた。

ssh-keygen -t rsa -b 4096 -f deploy_key.pem -N ""

しかし今の github は、上記の様なコマンドで作成した鍵 (RSA SHA-1) はだめとのことだ。

github.blog

ECDSA で作成する

こうする。

ssh-keygen -t ecdsa -f deploy_key.pem -N ""

コレデヨイ。

引き続き利用できているパターン

Keys with a valid_after date before the deadline (November 2, 2021) may continue to use SHA-1 signatures for the time being.

期限 (2021 年 11 月 2 日) より前の有効な日付を持つキーは、当面の間 SHA-1 署名を引き続き使用できます。

とのことなので、お目溢しというか様子見という感じっぽい。 タイミングを見て入れ替えておくのがよさそう。

作業時間

memo

へえっ、などと思いながら眺めていた。

www.blockchainengineer.tokyo

文意からするとマネージメント側がエンジニア側に配慮する、と読めたんだけど、このあたりで手法としてアンガーマネジメントとかが有効になってくる、というふうにつながるのかな。

わりとワンマンアーミーで対応する仕事が多くて、人が多いプロジェクトにアサインされるとどうしても他人に聞くのが苦手でなあ。

「それは別の話や！」と言われそうだけど、だからといって全部マネージメント側に相談してると、そっちが機能不全になってくるのはわかるのでちょっと悩んでいる。

RDS で LOAD DATA LOCAL INFILE を実行する

AWS RDS

いつも忘れて調べるんだけど、正解がｼｭｯと出てこないのでインターネットの敗北。 我の勝利〜。

--local-infile=1 を利用する

デフォルトで用意されるパラメータグループか、それに準拠するパラメータを利用していれば、 --local-infile=1 を付けて mysql コマンドを実行すればよい。

以下は扱う CSV ファイルが /tmp/example.csv として設置されている前提で書いています。 なんで /tmp/ かっていうと mysql コマンド以下から読み取れるファイル、権限設定を考えるのがめんどくさいからですね。 /tmp/ サイコー（こういうヤツが事故を起こす）。

mysql CLI から実行する

mysql -u ${ユーザ名} -p -h ${エンドポイント} --local-infile=1 ${データベース名}
Password:

mysql> LOAD DATA LOCAL INFILE '/tmp/example.csv' INTO TABLE ほんにゃかふんにゃか;

コマンドを流し込む

mysql -u ${ユーザ名} -p -h ${エンドポイント} --local-infile=1 ${データベース名} < ./example.sql
Password:
example.sql
USE ${データベース名};

LOAD DATA LOCAL INFILE '/tmp/example.csv' INTO TABLE ほんにゃかふんにゃか;

以上だ

以上だ……。

なんか太古の昔はパラメータグループから特定のコンフィグを変更する、とかお作法あった気がするんだけどよく覚えてないです。 やったね！

おじいさんに選ばれたのは大きなトランザクションでした

AWS RDS

RDS で LOAD DATA LOCAL INFILE って素直に使えるんだっけ？ と思って調べていたら以下のような記述を見つけてしまった。

バイナリログ作成を有効にすると、トランザクションが大きい場合、IOPS とディスク消費量が 3 倍になります。これは、ディスクに書き込まれるバイナリログキャッシュ、ディスク容量の消費、書き込みごとに増える IO が原因です。

ゲーッ！

いままで MySQL は最大でも 2 倍 (変更対象のデータベースやテーブルを取得してメモリに乗せる -> 流れてきた変更をメモリ上で実行する -> 実データ領域に新しくフラッシュ -> 既存のデータを削除してまるごと入れ替え) みたいな認識だったので、「あーなるほど binlog……」という感じだった、

と思ったら、以下のように書いてあり。

トランザクションが小さい場合、バイナリログ作成により、データのロードに必要なディスク書き込み数が 2 倍になります。

大きい・小さい、という粒度がサッパリわからんので恐ろしい……。 基本のラインとして、ディスク容量は 3 倍・メモリ容量は 2 倍、とおぼえておくと良いのかもしれない、というお話でした。はー RDB にまつわるシステム難しい。

docs.aws.amazon.com

CloudFront のオリジン (S3) に加えた変更をすぐに反映する

AWS CloudFront

キャッシュ無効化、という手法があります。

soypocket.com

ただこれ運用戦略的に正しいのか？ みたいな疑問符はあるんで、今回は「開発中だったり本番向け環境じゃない」という前提のもと、キャッシュの時間を調整します。

キャッシュポリシー

前回の記事でも掲載していますが、デフォルトの設定で作成すると、キャシュポリシーは CachingOptimized というヤツが選択されます。 これはキャッシュ保持時間が以下のようになっています。

最小 TTL (秒) 最大 TTL (秒) デフォルトの TTL (秒)
1 31536000 86400

ウーン、長い！

でまあどうするか、というと全部クラスメソッドの記事に書いてあるんですが、キャッシュ時間が極端に短いキャッシュポリシーを作成して、そいつをビヘイビアで設定します。

dev.classmethod.jp

CachingShoter

サイドメニューのポリシーからカスタムポリシーを作成します。

最近隠れてて思い出しにくいメニューくん

最小 TTL (秒) 最大 TTL (秒) デフォルトの TTL (秒)
10 10 10

クラスメソッドの記事でも語られていた通り、 0 にするよりは短時間でもキャッシュを設定すれば RefreshHit で更新がない限り再利用されそうなので、短時間で設定する意味はありそうです。

デフォルトの CacheOptimized との際は TTL 時間だけ

ビヘイビアに設定する

こんな感じ。 名前はもっといいのつけてくださいませ。

ディストリビューション > ビヘイビア

フロントエンドを CloudFront (S3) で配信する

AWS CloudFront

React とか Vue あたりで作って、 npm run build で出力したやつをフロントエンドと呼んでいます、雑ゥ！

とにかくこれを S3 にぶっこみつつ、CloudFront で配信します。 最近のウェブ系はだいたいこんな感じですよねというヤツのふりかえり。

続きを読む