タグ: infra

投稿日:

Raspberry Pi Zero WHでNASしたい、失敗録1

配線

私はRaspberry Pi Zero WHを所有していて、これまで自宅の室温を記録してサーバーに送信していた。突然NASを組みたくなり、これを利用できないかと考えた。

ざっくりラズパイにストレージが接続さえできればあとはどうにでもなりそうだったので、アダプター類を購入して準備した。具体的には、Zero WHはUSB micro-B凹端子しかないので、ここから

  • USB micro-B凸 to USB A凹 変換
  • USB A凸 to USB A凹 ハブ（給電機能つき）
  • USB A凸 to SATA

の3段階を経てタンスに打ち捨てられていたHDDに接続。つないでlsblkするだけで認識できた。

HDDの準備

母艦側PCでHDDの中身を適当にサルベージしたあと、フォーマットしてLUKS暗号化しつつBtrfsでパーティションを作成。このあたりは全部UbuntuのdiskユーティリティでGUI操作可能だった。ただしGUI上でBtrfsを選択するためにはaptでbtrfs-progsを入れておく必要がある。

Raspberry Piのソフトウェアレイヤーの準備

よくあるチュートリアルのようにOpenMediaVaultを入れようとしたのだが、そのためにはRaspberry PiのOSがGUIをサポートしないバージョンでなければならない。そのために面倒な思いをしてOSを入れ直した。しかし改めてOMVを入れようとしたが、一般的なインストールスクリプトはRaspberry Pi Zeroには対応してないらしい。

RPi revision code :: 9000c1
This RPi1 is not supported (not true armhf).  Exiting...

仕方なくsambaに方針転換してインストールしてみた。

HDDをマウントする

LUKSで暗号化されたストレージは先に

sudo cryptsetup luksOpen /dev/sda storage

する必要があるのだが、なんとこれを実行するメモリが足りなかった（そんなことある！？）

Not enough available memory to open a keyslot.

ので、HDDを再フォーマットしてチャレンジします…

投稿日:

静的サイトをS3にデプロイしてCloudFrontから配信する

世界中で一億回やられてる作業なので僕が言うことはない。これ読む。終わり。いつ書かれたものかよくわからないけどAWSのドキュメント類は割と頑張って最新の状態に追従してるので信頼していい。

https://repost.aws/knowledge-center/cloudfront-serve-static-website

  • S3バケット作る
    • 静的ウェブサイトホスティングは無効でいい
  • CloudFrontディストリビューションを作る
    • Origin access control settingsを選ぶ
    • ディストリビューションを作った後にS3にコピペするためのポリシーのコピーボタンが表示されるので、そこでコピってS3のアクセス許可→バケットポリシーにペーストする

https://hogehoge.cloudfront.net でindex.htmlにアクセスさせたい

CloudFront側のディストリビューションの設定からデフォルトルートオブジェクトをindex.htmlに設定する

https://repost.aws/questions/QU2waf6J-gRQWvvYu8jysr4Q/questions/QU2waf6J-gRQWvvYu8jysr4Q/cloudfront-distribution-not-serving-s3-bucket-pages-unless-index-html-included-in-url

その他のhtmlファイルに.htmlなしでアクセスさせたい

S3側でhtmlファイルの.htmlを削除し、Content-Typeをtext/htmlにする（大抵最初からなってそう）

https://medium.com/@gauravduttkale/static-aws-s3-website-pages-without-html-extensions-12db3e15e153

投稿日:

新しいことへの挑戦とリファクタリングを同時にしてはならない 五木寛之『生きるヒント 自分の人生を愛するための12章』を読んでいる

新しいことへの挑戦とリファクタリングを同時にしてはならない

サーバーコスト節約と技術的チャレンジを同時にやろうとしてk8sがわからなくて遅れているけどとりあえずサーバーコストだけでも落としたほうが良い。一番の金食い虫のt2.microのインスタンスを早急に潰したい。

その後さくらの方に全部移してみて、それでスペック足りるようだったら一旦終わりにしよう。大半のアプリケーションは常時起動が前提だからElasticである必要がない（何にでもElasticを注ぐAWS）。

五木寛之『生きるヒント 自分の人生を愛するための12章』を読んでいる

ぼんやりと落ち込んでいた時期に友人に勧められた本。今4章。

筆者が人生経験と知識に基づいて、「こうあると人生が楽しいんじゃないか」という話を取り留めなく書き連ねている。職業柄厳密に事実を書いた本を読むことが多いけど、こういう「私の感想」全開の本というのも良い。時間も空間も超えて他人の言葉に触れられるという本の特質を鑑みれば、むしろこういう本こそ読書の楽しみなのだと思う（まあ金持ってるジジイだから余裕ぶっこいた物言いができるんだよね、と鼻白むようなところもないでもない）。

3章「悲む」ではまず明治時代に「悲しいではないか」を挨拶とした若者たちがいたことに触れ、人生には悲しみが満ちていることを認め、現代の娯楽が明るさを求めすぎていることを指摘し、私達はもっと率直に悲しんで良いはずだと主張する。

みんなが、〈暗い〉と言われることを恐れている。そして明るく軽快で楽しげであることを求めている。
これはひとつの病気ではないかと、ぼくには思えるのです。

これは僕もその通りだと思う。アニメを見ていてキャラクターの底なしの明るさと作品に満ちるエネルギーに圧倒されてしまうことが多い。思えば記憶に残るお気に入りの作品は静かで悲しいものが多い。

仕事をしていても、目標は高く輝かしく、失敗も問題点の分析と修正して次は頑張ろうというエネルギーに転化される。もちろん営利企業だからそのエネルギー、欲望でカツオのように泳ぎ続ける宿命にあるわけだが、一人の人間としてはついていくのが辛いときもある。

投稿日:

k8sデカスギSGSG

t4g.microの上に小さいクラスタ立てて練習しようとか思ってたけど、プロダクション向けのクラスタ立てツールであるkubeadmを走らせてみたらいきなり「メモリは最低1700MB用意しろ」とか言われてひっくり返ってる。ノードも複数台で本格的にやることしか想定してなさそうだし、これどうすればいいんだ（世の趣味でkubernetesで使っている人間は結構なインフラコストを払ってやっているのか？EKS最小構成でも月額73ドルらしい）。

k8sはクラスタ自体が容易に作成・管理できるものではないといろいろな場所で言われていたが、やってみてようやく規模感が理解できた。そして困った。

minikubeはproductionに使うなと繰り返し書かれているが、練習だからと割り切って使ってしまうのもありだろう。

また k8s lightweight とかで雑に検索してみると

  • k3s
  • microk8s
  • k0s

などがヒットした。k3sならいけるか、見てみよう。あるいは自宅に物理鯖置いてそこにクラスタを組み、トンネリングツールか何かで公開するという方法もあるのかな（もう全く安くないが）。

投稿日:

k8sをやってみる―サービスの公開―

サービスを公開する

https://kubernetes.io/ja/docs/tutorials/kubernetes-basics/expose/expose-intro/

なんかいろいろ公開の種類もあるが、随分ローレベルだなあと思ったらServiceとは別にIngressというやつがあるらしい。

https://kubernetes.io/ja/docs/concepts/services-networking/ingress/

Ingressにはいろいろな実装？がある。kubernetes自体が未知の領域なのでなるべく慣れたものに寄せるため、nginxによる実装を使う。

https://kubernetes.github.io/ingress-nginx/deploy/

インストール方法に with kubectl apply, using YAML manifests がある。嬉しい。

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.6.4/deploy/static/provider/cloud/deploy.yaml

で必要なリソースが諸々立つらしい。先に作っていたDeploymentとここで作るリソースを統合するためkustomizeを導入する。と言っても

resources:
- deployment.yml
- https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.6.4/deploy/static/provider/cloud/deploy.yaml

と書かれたファイルを用意し、起動コマンドを kubectl apply -k . に変更するだけだ。

https://github.com/chao7150/barrack-k8s-spec/commit/977fb3c90989f96c5a070508e90aad45b570adad

この段階でこれらのファイルを保存しておくGitHubのリポジトリを作った。

本題に戻って外部からいい感じに内部のサービスにリクエストが通るように進める。

https://kubernetes.github.io/ingress-nginx/deploy/#local-testing

既にDeploymentは存在するとして、exposeでそのDeploymentを公開し（これはServiceを立てることと等しいので後々ymlでそれを書く）

kubectl create ingress demo-localhost --class=nginx \
  --rule="demo.localdev.me/*=demo:80"

でアクセスをDeploymentに向けるようなingressを立てる。classはいろいろあり得るingressの実装のなかでingress-nginxを使いますよという意味。ruleは demo.localdev.me/* へのアクセスをdemoという名のDeploymentの80番ポートにフォワーディングしますよという意味。

なんで demo.localdev.me がlocalhostに向いてるんだよと思って調べてみたら

https://qiita.com/masahata/items/89b2be02ee36b82cfced

このドメインを誰かが取得して 127.0.0.1 に向けているらしい。マジかよ。そして何の説明もなしにやるなよドキュメントで。

ここから先は本番のクラスタでやることらしいので、次回は本番のサーバにクラスタを組んでもろもろやっていくか。本番のサーバは既にgotosocialで稼働しているので、nginxでgotosocial以外へのアクセスをk8sクラスタに流す方針でやってみる。SSLオフロードとかも前段nginxでやっちゃいたい。

投稿日:

サーバーゼニ節約&kubernetes入門

ふと毎月のサブスク費用を確認したらAWSとさくらインターネットで月額5000円くらいかかっていて、いくらなんでも辛いのでこれを圧縮する。

原因は必要以上に多くのサーバーを稼働していること。現在稼働しているのは3つ。

さくらインターネット 2GB

  • 1738円/月
  • 2017年から借りており、中途半端な技術的挑戦の残骸が最も多い
  • 金額に対するスペックが良い

積載物

AWS EC2 t2.micro

  • 1544円/月

積載物

AWS EC2 t4g.micro

  • 1076円/月
  • AWS謹製のGravitonプロセッサなので安くて高性能。ただしArm。

積載物

  • gotosocialインスタンス

移行計画

どうしたものか…

とりあえずEC2は新世代ほど高コスパの原則があり、t2.microはt4g.microに移行すべき。自分の学習を考えるとさくらはやめてEC2に揃えたい。全部t4g.microに相乗りを狙ってみようか。

そしてどうせならkubernetesに全部載せてみたい。複数のアプリケーションを相乗りさせるときのトラフィック管理をこれまではjwilder/nginx-proxyでやっていたが、もうちょっとナウいやつに移行して監視とかも統一的にやりたい。