お引越ししました。

WordPressのblogを自鯖運用することにしたので
URLが変わりました。

うさぎでもわかる

WordPressでblogを始めるとき、セキュリティ周りの整備や運用に自信がなくて
AWSのAMIでWordPressの構築自体はできたのだけれども
自鯖でホスティングはもう少し慣れてからにしようと思ったの。

そろそろ自分でホスティングしても良いかなぁなどと思いつつ
データの移行方法について調べたところ
プラグインが用意されていて意外と簡単にできることが判明したので
引越しに踏み切りました。

これからはHTMLやCSSはもちろんPHPでも何でも触れるので
どんどん改造していきたいー!
WordPress.comでも、3000円/月のコースに登録すれば
HTML/CSSの編集やプラグインの利用は可能なの。
おそらくフロントエンドとして練習のためになら
それらの有料コースに登録していたのだろうけれども
インフラとしてやっていくのなら、自分でホスティングする一択でしょ!
ということで、構築とっても楽しかったです😃♡

Deep Lunch

帰宅後、ソファで寝落ちしてしまったので
blog書こうにも昨日のことなんて覚えていません!

お昼何食べたか思い出そうとして思い出しました。
濃い感じのお昼でした。
職場のひと数人で魚を食べたのですが
ほぼ今まで会話をしたことがないメンバーで
「初っ端の話題がこれか」
ってレベルの内容だったの。
おそらく皆お互いにそう思いつつも
ブレーキかける人が不在で突き抜けてしまった感じでした。

なかなかディープなお昼でした。
おそらく人生において最初で最後のDeep Lunchです。
# DeepLunch

週末は渋谷のもくもく会と
PHPカンファレンスです。
久しぶりに盛り沢山なので楽しみ〜😃

あと自作OSについて
OS自作入門でやりたいなと思っていて

30日でできる!
なら3ヶ月あればできる!
って思っていたのだけれども
なかなかハードルは高いなと感じていて
これとは全く別の記事で

OSを書く:初歩から一歩ずつ | POSTD
この内容であれば
頑張れば1日でできそうだし
OS自作入門の序盤と重なる部分もあるので
「アセンブリ言語を触ってみる」
みたいな感じで、やってみたいなぁと思いました。

さながら目玉焼きをつくるような

きゃーーーーー
WordPress.comってWPのホスティングサービスを使っていて
WordPress.orgで(ホスティングサービスを使わずに)自鯖運用したいけれども
どうやって今のblogから、引越し先のサーバーへデータ移行するのかなぁ
なんて考えていたら移行方法のページ見つけた!
https://move.wordpress.com/exportimport-content/
エクスポートとインポートできるのか!わーわー
suwa3.meドメイン持っているので
さっそくwp.suwa3.meとかでサブドメイン切って移管作業やりたいです🙋
今週末のもくもく会かなぁ
blogなんだかんだ1年間毎日休まず続けているの。

TODOできたぁ
今週中にがんばるぞい😃

お仕事するようになって作業スピードが10倍くらい速くなったので
目玉焼きをつくるような手際の良さでサーバー構築したいし
クッキーを焼くようにサクッとDockerfile書けるようになりたいです。

エムグラム

エムグラム診断やってみました。
質問に頑張って答えたよ😃

なるほどーだったぁ。

週末に勉強会に参加したり、自鯖内で作業したりするの
もともと趣味から入って
週末に開発コミュニティなどに参加していたので
いろいろと教わった際、必然的に
『仕事も趣味も人生そのものがエンジニア』
みたいな人たちばかりで
エンジニアとはそういうものだと思っていたの。

そうじゃない人もいるというのがカルチャーショックだった。
しかし普通に考えたら、休日は休むための日だし
当たり前といえば当たり前なのかもしれない。

むしろ、感覚的に趣味と仕事の境界線が曖昧になってしまうかもしれないの
危ういなぁと思う。
先々月のTODOリストだとか見るとconfig編集していて
「まだコドモンで働いていないはずなのに何で仕事しているんだ?」
って一瞬ビビったら普通に趣味鯖で遊んでいただけとか

色々なことが出来るようになるのとても楽しいし
楽しむぶんには問題ないのだろうけれども
仕事は仕事なので(たとえ趣味鯖と同じ作業だとしても)
切り替えてキチンとこなすべきだよなぁと思う。

趣味鯖はBOT走らせ放題の実験cron回し放題のDBガンガン触って遊べるので、これからもマイペースにやりたいことやるの😃

モノリシック

先日の勉強会でLinuxの話になって
「モノリシックカーネルとマイクロカーネル、あなたはどちらが優れていると感じますか」
と訊かれて
「何じゃそりゃ?」
となったので、そこで聞いたことと
調べたこと、ふんわりと考えたことをまとめます。

モノリシックカーネルは一枚岩ということで
機能が分割されていないため実行速度が速い。

マイクロカーネルは逆に、様々な機能がモジュールとして分割されているため
一部のみの変更や更新などに対応することができる。

カーネルにおける設計思想ということだな、と理解しました。

以下にも詳細が載っています
モノリシックカーネルとマイクロカーネル | Linux技術者認定試験 リナック | LPI-Japan

すなわち、「完全にモノリシックカーネル」「完全にマイクロカーネル」というのは、最近では少なくなってきたのです。アーキテクチャや機能の多様化・進化に伴い、「この機能はカーネルに組み込む」「この機能はモジュールにする」のように使い分けるほうが、設計上もパフォーマンスの上でも好ましいため、と言えるでしょう。

https://linuc.org/study/knowledge/460/

これを読んで思い出したのが
VimとEmacsのエディタ論争で
シンプルさか、もしくはカスタマイズ性を求めるのかという部分では
モノリシックかマイクロか、という部分で重なりました。

「用途に合わせて」
というのが前提にあるにせよ
どちらが自分自身の考え方にあっているのかというのは
対象に合わせて自分を変化させるのか
対象を自分のコントロール下に置くのか
そういったところに帰結するような気がする。

何にせよ、自作OSやりたいので
「カーネルにも色々と種類があって、設計思想的なものがあるのだなぁ」
と知ることができたの良かったです。

CodeDeploy

sidekiqの設定をAnsibleで自動化したものを
AWS CodeDeployで自動化しようと格闘しました。
とりあえず途中まで進んだものを備忘録的に書いておきます。

まずIAMロールを作成

CodeDeployダッシュボードへ移動し
そのロールARNを元に
アプリケーション、デプロイグループの作成をします。

デプロイタイプはシンプルなものを選びます。
対象のEC2インスタンスを選択します。

デプロイ設定は、今回ES2インスタンス1台なのでOne at Timeを選択します。
詳細は以下URL
CodeDeploy でデプロイ設定を使用する – AWS CodeDeploy
ロードバランサーはEC2内部でNginx稼働しているため、今回は指定しません。

デプロイの作成で
GitHubのトークン名は
一度ブラウザでGitHubからログアウトして
アカウント名を入力してあげます。
以下URL参照
ステップ 6: アプリケーションをインスタンスにデプロイする – AWS CodeDeploy

次はリポジトリの紐付けです!

肝心のAnsibleリポジトリが
個人的に、まだまだまとめられてないなぁと感じるので
ディレクトリ掘って整備が完了次第、続きをやりたいと思います。

PORTでもくもく

PORTのもくもく会に行きました。
先月行けなかったので、少し久しぶりな感じでした。
だんだん知り合いが増えてきて、ホーム感増してきたの嬉しいなぁ。

LTをやったので懇親会にも初参戦したよ。
あまり話したことない人とたくさん話せて楽しかったです。

主に趣味鯖上で運用しているSNSの
dumpのcronを書き換えたりsidekiqの設定を変えたりしました。
備忘録を残します。

$ crontab -l 
0 0 * * * docker run --link mastodon_db_1 --volume /opt/backup:/mnt/backup --network mastodon_internal_network postgres:9.6-alpine /bin/sh -c "pg_dump -U postgres -h mastodon_db_1 postgres | gzip -c > /mnt/backup/dump-`date +'%Y-%m-%d'`.sql.gz; exit" > ~/cron.log 2>&1

本当はローカルにdump取りたいの
でもとりあえずdiscfullでEC2が定期的に落ちるのどうにかしたいので

`date +'%Y-%m-%d'`

ここの部分を削除して
dumpファイルが最新のものに上書きされるようにしました。
つまりこうです。

$ crontab -l 
0 0 * * * docker run --link mastodon_db_1 --volume /opt/backup:/mnt/backup --network mastodon_internal_network postgres:9.6-alpine /bin/sh -c "pg_dump -U postgres -h mastodon_db_1 postgres | gzip -c > /mnt/backup/dump.sql.gz; exit" > ~/cron.log 2>&1

これでいったんは大丈夫なはず。
運用し始めて数ヶ月経つけれども、一度もdumpファイルが必要になったことないので
暫定的な対処です。
無料枠でRDSを立ててDBの引越しが済めば
これらのバックアップは必要なくなるし、監視もしやすくなるので
できればそうしたいなぁ。
無料枠が切れたら、またPostgreSQLに戻します!

sidekiqの方は、かなり分からないので
「試しにやってみて期待した挙動と違ったらまた考える」
状態なのですが
config以下にあるsidekiq.ymlを編集して

$ vi config/sidekiq.yml
---
:concurrency: 1
:queues:
[default, 6]
[push, 4]
[mailers, 2]
[pull] 

最初ここは:concurrency: 5だったのだけれども
並列処理しすぎて詰まりすぎているのでは?という懸念があり
一度メンテナンスモードに切り替えて
リクエストを一つずつ処理させるモードに変えてみました。

メンテナンスモード中は管理者画面に入れないので
一晩この設定で試してみたら
明日は通常モードに切り替えて
sidekiqの管理画面からジョブキューのログを見てまた判断したいと思います。

今日はLTの資料を作っていたら思いのほか時間が溶けて
「とりあえず暫定的な対処!」
みたいな感じになってしまった😣
他鯖の影響を受けてリクエスト急増時に
EC2へsshログインしづらくなるのがしんどい。
ラズパイなどにAnsibleを置いて、sshログインなかなか出来なくても
粘り強くログインするまで頑張るAnsibleに設定して
メンテナンスモードへの切り替えだけでも自動化させたいです。