ごらくらいふ

プログラミングしたりゲームしたり

xyzドメイン切れたしmastodonインスタンスの更新を始めた

.xyzドメインがお役御免となった。

.devドメインのためにGoogle Domainsを使い始め、ついでに .com ドメインも取得したので、もうxyz維持する必要もないのだ。

これに伴い(自動更新で意図せず)生きてるVPSの整備を再開しようと思いたち、今mastodonの更新をしてる。

yajamon.hatenablog.com

この記事のやつね。(当時v1.2.2、現在v1.3.2)

2019/06/25現在、mastodonの最新バージョンは v2.9.2らしいので、正式バージョンだけでもおよそ50件近い更新作業が必要らしい。早速 v1.3.3 に更新した。 一日に一件程度のペースで着実に更新していけばなんとかなるかな…。

雑多にやったこと

サービス再起動のたびにコマンド打つのが面倒で、シェルスクリプトにまとめた。

#!/bin/bash

echo "mastodon stopping..." >&2
service mastodon-streaming stop 
service mastodon-web stop 
service mastodon-sidekiq stop 

echo "infra restarting..." >&2

service rh-redis32-redis restart
service httpd24-httpd graceful

echo "mastodon starting..." >&2
service mastodon-sidekiq start
service mastodon-web start
service mastodon-streaming start

もはや && でつないでさえいないけれど、まぁこれでいいのだ。initスクリプトにrestart足してもいいんだけどね…

参考リンク

また飽きたりしても大丈夫なように、参考リンクとか残しておく。

gitが追跡していないファイル(untracked files)を消す方法は、ちゃんとgitが用意している。(git clean)

git help読んでないマンが露呈していた!!

追跡していないファイルの削除には git clean コマンドを使用するとよい。

# dry-run。対象ファイルを確認できる。 
git clean -n

# 実施。
git clean -f

# 追跡していないディレクトリも対象とする。
git clean -n -d
git clean -f -d

git clean-n, -fのいずれかを必ず付与しなくてはならない。 間違い減らしの取り組みっぽい。

git-scm.com

yajamon.hatenablog.com

Gitでuntracked filesの一覧を出したあと削除するとき、ヒストリ展開を使わなくてもxargsで十分削除できた

xargsうまく使えないマンが露呈している。

結論

# 一覧から消したいものだけgrepで絞る。
git status --untracked-files | grep '*.foo'

# コマンド履歴から直前のコマンドを持ってきて、xargsを加えて消す。
git status --untracked-files | grep '*.foo' | xargs rm -iv

yajamon.hatenablog.com

Gitでuntracked filesの一覧を出したあと削除するとき、ヒストリ展開を使えば楽だった

git resetでちょっと巻き戻したときとか、非追跡なファイルの削除にはいつも手間取っていた。 まずコマンドで一覧を出して、絞って、同じコマンドのあたまに rm をつけて。

手作業でめんどうなことこの上ない。でもシェルは強力なツールなのでしれっと解決してしまう。

結論

git status --untracked-files | grep '*.foo'
rm -iv $(!!)

gitで管理していないファイルのリストを見る

git status --untracked-files

ここからさらに処理したい対象をgrep等で絞ってもよい。

ヒストリ展開を使って指定

bash, zshで確認したが、ヒストリ展開機能というものがあり、特定の記法を行うとマッチするコマンドに置き換えてくれる。

!! と入力すれば、直近のコマンドとなる。

よって非追跡ファイルのリストをサブシェルで確認し、 rm のパラメータにしてしまえばよいのだった。

現在のbranchを(branch nameを書かずに)リモートにPushしたい

結論

git push -u origin $(git branch --contains | cut -d' ' -f2)

git branch --contains=[ref]はrefの示すcommitを含むbranchを列挙する。 特に指定しなかった場合、HEADを指定したものとする。

branchをチェックアウトしている前提なので、cutコマンドで*を削っている。

これで^Rのコマンド履歴から使い回せるようになった。TAB叩くコスト削減。

AWS ECSデビューした

AWS ECS (elastic container service)デビューした。

基盤には AWS Fargateを採用。

AWS ECSとは

Amazon Elastic Container Service (Amazon ECS) は、Docker コンテナをサポートする拡張性とパフォーマンスに優れたコンテナオーケストレーションサービスです。これにより、コンテナ化されたアプリケーションを AWS で簡単に実行およびスケールできます。Amazon ECS では、独自のコンテナオーケストレーションソフトウェアをインストールおよび操作したり、仮想マシンクラスターを管理およびスケールしたり、それらの仮想マシン上のコンテナをスケジュールしたりする必要はありません。

Amazon Elastic Container Service (ECS - 高性能な Docker コンテナ管理) | AWS

  • 基盤にEC2か、Fargateを選択することができる

EC2を選んだ場合、コンテナのタスクは自身のEC2インスタンス上で稼働する。

AWS Fargateとは

AWS Fargate は、サーバーやクラスターの管理の必要なしにコンテナを実行するための、Amazon ECS に対応したコンピューティングエンジンです。AWS Fargate を使用すると、コンテナを実行するために仮想マシンクラスターをプロビジョニング、設定、スケールする必要がありません。これにより、サーバータイプの選択、クラスターをスケールするタイミングの決定、クラスターのパッキングの最適化を行う必要がなくなります。AWS Fargate により、サーバーやクラスターの操作や検討が不要になります。Fargate を使用すると、アプリケーションを実行するインフラストラクチャの管理ではなく、アプリケーションの設計や構築に注力できます。

AWS Fargate – サーバーやクラスターの管理が不要なコンテナの実行

たとえば、コンテナを動かすために割り当てるリソースと、EC2に確保したリソースとの辻褄合わせ作業が必要なくなるそうな。

とりあえずサンプルを立てた流れ

sample-appというコンテナを動かしてみたのだけど、手順がフレンドリーすぎて画像を付けて解説とか必要ない。 ↓に列挙した感じの流れで進めていったらできた。

  1. AWS ECSサービスをひらくと、今すぐ始める!というボタンがあったので押す
  2. Containerの設定
    • 使用するコンテナイメージはなんなのか(sample-app)
  3. Taskの設定
    • メモリ(512MB), vCPU(0.25)の設定
  4. Serviceの設定
  5. Clusterの設定
    • ながれに任せて(名前付けたくらいしかしてない)

動作確認

Clusterが作られて、サービスの内容を確認するとグローバルIPが振られていることが確認できた。 そのIPにアクセスすると、HTMLドーンと表示されて完了。

ECSのコンテナを停止させる

sample-appの流れでは、タスクはサービスによって自動で起動されたもののため、 停止させようとしたら「サービスの設定を変更して止めるように」注意された。

サービスの設定で、タスクの必要数を0にしたところ、ちょっと待ったらタスクが処分されて停止した。

あばよクラスタ

クラスタの削除を敢行したら関連して作ってくれたVPCやらネットワークゲートウェイやらサブネットやらもりもり消していった。 綺麗な仕上がりである。

感想

ECS初めて見るのは思ってたより簡単だった。 コンテナ引っ張ってくるところに時間がかかるとかあるっぽいので、ECRにコンテナリポジトリを立てたら爆速になる?

Fargateになって、autoscalingでスケールアウトだけじゃなくスケールアップもできるようになってるはずだ! というなぞの確信があるので、minecraft on ECS (auto scale up/down)ができたら、 活躍できてないminecraftVPS(2GBリソース)をたためるかなぁという気持ち。

minecraft畳んでmastodonを1GBリソースサーバから引っ越しさせたほうがいいか。

というかminecraftサーバ動いてないときほんっと動いてないのでEC2で寝かせてても良いところではある。 だれがkickupするのっていうところを解決できればなぁ~~。

あるいは常時稼働しても問題ないほどの資金が調達できればいい。