カテゴリー: 勉強メモ

投稿日:

静的サイトを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

投稿日:

docker-composeのスタック名で結構苦労した話

そんなにちゃんと調べた記事じゃないです…

docker-compose upすると適当なstackが作られ、stack名はデフォルトでdocker-compose.ymlがあるディレクトリの名前になる。僕は複数のリポジトリでdocker-compose.ymlをdockerディレクトリの下に入れているから、複数のstackの名前が docker になって被る。そうするとstack内のコンテナとかボリュームの名前も docker-app とか docker-db とかになり、他のstackとぶつかりまくる。特にボリュームの名前の衝突は最悪で、特にハッシュ化とかしてないので同じボリューム名だとホストマシンの同じ場所にマウントされてDBのスキーマ違いますと怒られたりする。

stack名をちゃんと指定するにはdocker-composeの-pオプションを使うのだが、そもそもdocker-composeというのはupとdownしか覚えられない人間が使うもので、アプリケーションによって適切なオプションをつけて運用するのは不可能だ。結局僕はコンテナやボリュームの名前にアプリケーション名のプレフィックスをつけることで問題を回避したのだが、docker-compose.ymlのトップレベルにnameを入れておけば解決するらしい？（未検証）docker-compose.ymlの仕様（というかdocker系のドキュメント）、ググってもどれが信用できる情報かわからなくていつも適当にしちゃう。

投稿日:

digのオプションが多すぎる

ってmanに書いてあって笑った。

BUGS
       There are probably too many query options.

もっと面白いバージョンもあるようだ。翻訳前の文章は見つからなかった。
https://linuxjm.osdn.jp/html/bind/man1/dig.1.html

dig は "潜行性機能過多" を患っています。 これは開発中に潜在的な用途をいくつも考えていた結果です。 苛酷なダイエットをしたらきっとよくなるでしょう。 同様に、表示フラグとそれで指定できる表示項目の粗さとから、 これらがその場限りの必要性から追加されたものだということが わかるはずです。

ところでdigしたときのANSWER SECTIONの謎の数字って残りキャッシュ時間らしいんだけど本当ですかね？確かに減っていくんだけど。

投稿日:

新しいことへの挑戦とリファクタリングを同時にしてはならない 五木寛之『生きるヒント 自分の人生を愛するための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でやっちゃいたい。

投稿日:

k8sをやってみる―Deploymentを作る―

※この記事は私の学習のメモであり、有益な知見は含まれていません。読まないでください。

k8sのクラスタを作る

チュートリアルのnginxのコンテナを立ててスケールさせて…みたいなやつは大昔に一度やった。今回はymlファイルのアレ（何て言うんでしょう？）で宣言的に管理できる状態を目指す。

チュートリアルを読むといきなりMinikubeというやつが出てくる。

https://kubernetes.io/ja/docs/tutorials/hello-minikube/

kubernetesのクラスタを作るのにkubernetes hogeとかkubectl fugaみたいなコマンドじゃなくて別の何かが必要になるのか…

https://kubernetes.io/docs/setup/

kubernetesのクラスタを作る方法を選ぶためのページがある。ローカルでの開発にはminikubeを、プロダクションにはkubeadamということにしよう。

https://minikube.sigs.k8s.io/docs/start/

minikubeを入れた。

minikube start

するとkubectlが見つかりませんと表示された。そこで

https://kubernetes.io/ja/docs/tasks/tools/install-kubectl/#curl%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%A6linux%E3%81%B8kubectl%E3%81%AE%E3%83%90%E3%82%A4%E3%83%8A%E3%83%AA%E3%82%92%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E3%81%99%E3%82%8B

に従ってkubectlを入れた。あとでaptで入れればよかったと後悔したが、まあ良い。minikube deleteして再度minikube startするとなんとなく問題なさそうなログが出て作成が完了した。

ymlファイルを書いてなんかアプリケーションをデプロイしたい

k8sのドキュメントの中で情報を探すのに苦労したが、どうやら

https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/
https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/

この辺りを読めばいいらしい。ymlで設定ファイルを書ける機能はkubernetesの（というかkubectlの？）標準機能としてありDeclarative Managementと呼ばれていて、kustomizeはその拡張？のようなものだろうか。

そもそもどうやるとアプリケーションをデプロイできるのかというのを忘れてしまっているので、チュートリアルの内容をDeclarative Managementの作法で進めてみる。

チュートリアルによるとまずはDeploymentを作るらしい。

https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/#how-to-create-objects

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  minReadySeconds: 5
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

というファイルを作って同じディレクトリで kubectl apply -f . してみるとDeploymentが作られた。metadataとかselectorとか無くても動かんかｗ？と思って削ってみたらダメだった。これがホントの最小構成らしい。

次はこうして立てたコンテナに外からアクセスできるようにしたい。チュートリアルの方はしばらくデバッグ用と思われる kubectl proxy を使いながら基本的な操作の説明をするようだ。