今回の雪は降り始めが深夜からなので、前回のように帰宅ラッシュ時に入場規制乱発で大混乱とはならなかったが、朝は荒れるかな？
後日談。
今回の雪では、特に混乱はなかった模様。
You Tube 動画を流し見していたら、ボディビル関連の動画で「中胚葉型」とかいう聞きなれない単語が耳に入ってきたのでグーグル先生に聞いてみた。
ボディビル業界では、生まれつきの体質として「内胚葉型」「中胚葉型」「外胚葉型」の3種類、および、それらの混合型の体質があると考え、それに合わせた食事とトレーニングをすると良い、とされているらしい。
ボディビルに向いているのは「中胚葉型」で、ボディビル大会で賞を取れるのはこのタイプとのこと。
中胚葉とかって卵の発生時にしか使わない単語だと思ってたわ。
マジかよ...。
なぜHTTPS化が必要なのか
いい記事だったのでメモ。
HTTPのままだと、中間者攻撃でブラウザにウィルス仕込まれる、ということが実際にあるらしい。 NSAとか国家レベルの機関なら十分実施可能で、実際に使われているとのこと。
そろそろ自宅鯖とオレのAWS鯖にもLet's Encrypt入れるかなー
tag:kubernetes,minikube,heapster
minikubeにはheapster(kubectl top nodeとかで使うサービス。CPU使用率とかメモリ使用率を表示)が入っていないので、入れてみる。
インストール方法は、helm & charts に頼るｗ
helm ( & tiller ) & charts は、kubernetes用の homebrew(MacOS X) とか chocolatey(Windows) とか yum(Red Hat) みたいなモン。
helm & tillerがyumのような普通のバイナリパッケージ管理システムと異なる点は、tiller serverが常駐してkubernetesサービスとしてアクセス可能である必要があること。 (要するにクライアント／サーバ型のシステム）
なお、helmでインストールしたchartの情報はkubernetes上のconfigmapとかsecretsに保存されているので、 helm listでインストールしたRELEASE-NAME一覧が表示でき、 helm history RELEASE-NAME とすると、該当するパッケージの履歴が見物できる。
# minikube開始 minikube start # helm設定ファイル初期化＆tiller server(deployment+service)をkubernetesにインストール helm init # heapsterのchartのtar.gzを取得 helm fetch stable/heapster # tar.gzを展開 tar xvzf heapster-0.2.5.tgz # README.mdを読む。パラメータとして指定できる変数の一覧が書いてある。 # heapster/values.yamlにはパラメータの初期値が書いてある。 # service.typeをClusterIPからNodePortにする必要がある。（minikubeなので) # helmを使ってインストール。 # RELEASE-NAMEは my-heapster にした。これは helm のインストール管理用の名前。helm list で表示される。好きな名前をつけてOK。 # インストール先の namespace は kube-system とする。 # インストール先のnamespaceをkube-system以外にした場合は、 # kubectl top node 実行時に --heapster-namespace オプションにて # heapsterをインストールしたnamespaceを指定する必要がある。 # service.typeは --set オプションでコマンドラインから指定可能。 helm install --name my-heapster --namespace kube-system --set service.type=NodePort heapster # kubectl top node してみる kubectl top node
実行結果
george@KabyLakeS /c/home/minikube/charts $ kubectl top node NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% minikube 138m 6% 913Mi 48% george@KabyLakeS /c/home/minikube/charts $
CPU(cores)が138mとあるが、これは1CPUを1000mとしたミリCPUコア(?)という単位のようだ。
kubernetesでは、このPodはCPUリソースを100m使うよーとかメモリを100Mi使うよーとか、予約(require)できたりする。
予約で埋まったノードにはもうPodは新たに作成されないとか、そんな制御もできるようだ。
minikubeは１ノードしか無いので関係ないけど。
tag:kubernetes,minikube,heapster
前回は helm chart で heapster 入れたけど、実は minikube addon には heapster があった（涙）
前回インストールしたheapsterは helm delete --purge my-heapster で削除してから以下を実行。
# アドオンの一覧表示 minikube addons list # heapsterを有効にする minikube addons enable heapster # grafanaのWeb画面をブラウザで開く # デフォルトブラウザがEdgeだと、 http://192.168.99.100:30002/ は表示できないので、Firefoxとかで表示する minikube addons open heapster
グラフィカルに色々なメトリクスが表示できる。 が....。
george@KabyLakeS ~ $ kubectl top pod --all-namespaces NAMESPACE NAME CPU(cores) MEMORY(bytes) default my-kjwikigdocker-9f8498777-2hrc6 2m 201Mi kube-system heapster-jcqdn 0m 16Mi kube-system influxdb-grafana-h2mpj 8m 40Mi kube-system kube-addon-manager-minikube 24m 32Mi kube-system kube-dns-54d4f78785-4fns6 1m 43Mi kube-system kubernetes-dashboard-r8nk9 0m 19Mi kube-system storage-provisioner 0m 35Mi kube-system tiller-deploy-7594bf7b76-dqhq4 0m 22Mi george@KabyLakeS ~ $ kubectl top node NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% minikube 155m 7% 1466Mi 77% george@KabyLakeS ~ $
1.4Gくらいメモリ食っててワロタｗ
minikube heapster addon の内部構成はよくわからんけど、たぶん以下のような感じなのだろう。
heapsterは定期的に各種メトリクスを取ってinfluxdbに覚えさせる。 influxdbから情報を拾ってWeb画面に華麗にグラフ表示しているのは grafana (Ruby on Rails)。
minikubeはデフォルトでは2048MBメモリ構成でVMを起動するので、heapster + influxdb + grafana をセットで動かすとメモリ消費がヤバい結果となった。
なるほど、デフォルトでdisabledにされるaddonだな...。表示は華麗なんだけども...。
あと、kubectl top podの合計とkubectl top nodeの値が合わないのも変だな。なんだろこれ。
tag:freebsd,letsencrypt
Let's Encryptを使うなら、certbotというツールを使うのが良いらしい。
ssh george@n3050 ~ $ pkg search certbot py27-certbot-0.20.0,1 Let's Encrypt client py36-certbot-0.20.0,1 Let's Encrypt client ssh george@n3050 ~ $
python3.6用を使ってみよう。
sudo pkg install -y py36-certbot-0.20.0,1
root@n3050 ~ $ certbot-3.6 --help
-------------------------------------------------------------------------------
certbot [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] ...
Certbot can obtain and install HTTPS/TLS/SSL certificates. By default,
it will attempt to use a webserver both for obtaining and installing the
certificate. The most common SUBCOMMANDS and flags are:
obtain, install, and renew certificates:
(default) run Obtain & install a certificate in your current webserver
certonly Obtain or renew a certificate, but do not install it
renew Renew all previously obtained certificates that are near
expiry
-d DOMAINS Comma-separated list of domains to obtain a certificate for
(the certbot apache plugin is not installed)
--standalone Run a standalone webserver for authentication
(the certbot nginx plugin is not installed)
--webroot Place files in a server's webroot folder for authentication
--manual Obtain certificates interactively, or using shell script
hooks
-n Run non-interactively
--test-cert Obtain a test certificate from a staging server
--dry-run Test "renew" or "certonly" without saving any certificates
to disk
manage certificates:
certificates Display information about certificates you have from Certbot
revoke Revoke a certificate (supply --cert-path)
delete Delete a certificate
manage your account with Let's Encrypt:
register Create a Let's Encrypt ACME account
--agree-tos Agree to the ACME server's Subscriber Agreement
-m EMAIL Email address for important account notifications
More detailed help:
-h, --help [TOPIC] print this message, or detailed help on a topic;
the available TOPICS are:
all, automation, commands, paths, security, testing, or any of the
subcommands or plugins (certonly, renew, install, register, nginx,
apache, standalone, webroot, etc.)
-------------------------------------------------------------------------------
root@n3050 ~ $
apachectl stop certbot-3.6 certonly --standalone --preferred-challenges http -d <ドメイン名>
certbot-3.6 certificates
(前略)
<VirtualHost *:443>
ServerName <ドメイン名>
DocumentRoot "/usr/local/www/apache24/data"
ServerAdmin <メールアドレス>
ErrorLog "/var/log/httpd-error.log"
SSLEngine on
SSLCertificateFile "/usr/local/etc/letsencrypt/live/<ドメイン名>/fullchain.pem"
SSLCertificateKeyFile "/usr/local/etc/letsencrypt/live/<ドメイン名>/privkey.pem"
(後略)
# virtual host の設定チェック apachectl -S # 設定ファイルの文法チェック apachectl configtest # apache再起動 apachectl restart
ふむ。httpsでアクセスできる。
tag:freebsd,letsencrypt
Let's Encrypt のサーバ証明書は有効期限が三カ月と短い。
このため、cronなどで自動更新にしている人が多いようだ。
renewする時は httpdは落とさなくて良いみたいだ。 後日談。renewする時にも httpd は落とす必要があった。
ウチの場合は以下のようなコマンドになった。
certbot-3.6 renew --post-hook "/usr/local/etc/rc.d/apache24 restart"
後日談。↑では動かないことが判明；；
rootユーザーからcrontabの登録を行う。
crontab -e
んー。crontabで90日ごとに更新ってどう表現すりゃいいんだｗ
90日の期限が切れる前に実行したい。 できればLet's Encryptのサーバが落ちていた場合も考えて、期限が切れる2週間前と1週間前に実行したい。 その次の更新は、そこから90日後に行いたい。 ...。
毎週更新チェックすればいいか。certbot側で更新のための通信が必要かどうかは判断してるし。
crontabの内容。
MAILTO=george PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin LANG=ja_JP.UTF-8 7 5 * * 4 certbot-3.6 renew --post-hook "/usr/local/etc/rc.d/apache24 restart"
too long didn't read（長すぎたから読まなかった）の略語・インターネットスラング。 転じて要約の意。Qiita等で見かけるときはこちらがメイン。
今北産業の意味でだいたいあってた。
tag:iphone
ちょうど２年縛りが解けたので、iPhone8 Plus 購入。108,000円(ソフトバンク)。
つーか、驚くほど外見変わらないなこれｗ 裏面はガラスになってるけど。
早速機種変更の移行儀式を開始する。
スマホ移行とは関係ないけど、手持ちのSUICAをiPhone8+に移行してみた。SUICAカードの方はもうチャージできなくなるそうだ。
iPhone8 Plusの印象だけど、本体から鳴らした場合音が良い感じ。 iPad Pro 10.5 inchの時もそう思ったけど、今回の音には驚いた。 iPhone6s Plusだと音が明らかに本体下のスピーカー穴から出てたけど、今度のiPhone8 Plusはガラス面の全面(前も後ろも)から音が出てるように感じる。 指でガラスに触れてると振動してるｗｗ マジで頭おかしい（褒め言葉
（指で本体右下のスピーカー穴を抑えると、メインの音はここから出ているのがわかるが・・・なぜか全面から聞こえるような気がするんだよなー。音位置測定（コロケーション）を誤魔化す処理が入っているのかしら？）
次回のiPhone購入は2年後の3月末から可能になる予定。
それではベンチマーク。iPhone8 Plusの方がiPad Pro 10.5より高速って出てるけどマジかｗｗ
| GeekBench4 | Single-Core | Multi-Core | CPU |
| iPhone8 Plus | 4240 | 10128 | Apple A11 Bionic @ 2.39GHz |
| iPad Pro 10.5 | 3966 | 9453 | Apple A10X Fusion @ 2.34GHz |
| iPhone6s Plus | 2524 | 4406 | Apple A9 @ 1.85GHz |
これは次のiPadの販売が近いかもしれん。
寝転がって使ってみた感想。すごく重いゾこれ。手首と肘が負けて折れるｗｗ
見た目あんまりイノベーションは無いけど、ハードウェアスペックの進化は凄まじい。 PCで考えたらこれくらい性能差があったら買い替えてもいいかも。
Ubuntu 16.04 LTS だと letsencrypt というcertbotに名前が変わる前の古いパッケージしかないので、 上のサイトで最新版拾うのが良さそう。
上のサイトでは、certbotチームはUbuntu向けにppaというリポジトリをメンテナンスしているので、そこのリポジトリを追加してダウンロードする手順が表示された。
sudo apt-get update sudo apt-get install software-properties-common sudo add-apt-repository ppa:certbot/certbot sudo apt-get update sudo apt-get install python-certbot-apache
apacheの設定ファイルも自動設定してくれるモードでチャレンジ。
sudo certbot --apache -d ＜ドメイン名＞ -m ＜自分のメールアドレス＞
ライセンス承諾するか？とメーリングリストに登録するか？の質問はインタラクティブに答える。
お。自動でvirtualHostの設定ファイルにSSL設定を追加してくれてる。
あとは、Amazon AWSのコンソール画面からport443を通すように設定。
ふむ。
cron設定でcertbot renewも忘れずに。
tag:minikube
minikube にも ingress addon がある。
NodePortはIPアドレス＋ポート番号でサービスを外部に出すのでわかりやすいという利点はあるけど、 サービスが増えてくるとポート番号30022はサービスなんだったっけ？となりがち。
ということで、minikubeでも ingress を使う。
詳しい話は上を参照のこと。
IngressはL7 LB（レイヤー７ ロードバランサー）って急に言われても...とお嘆きの貴兄には...どっかいいサイトないかな。
要約すると以下のようなお話。
余談だが、nginxはL4 SW(レイヤー４ スイッチ）とも呼ばれる。設定次第で(HTTPではない)DNS問い合わせ(UDP/53)とかもbackendに転送できる。
それでは早速有効にしてみる。
# minikube addon 一覧表示 minikube addons list # ingressを有効化 minikube addons enable ingress
残念なことにWindows用のdnsmasqは存在しないようなので、 minikubeに登録されたingressをWindows PCのブラウザから見物するためには手動でingress一覧を表示して、 特権モードで起動したメモ帳からC:\Windows\System32\drivers\etc\hostsを書き換える。
# kubectlコマンドで登録されたingressを表示
kubectl get ingress
# jsonpathを使って /etc/hosts 形式で、ingressのhostsを出力する
kubectl get ingress -o 'jsonpath={range .items[*]}{.status.loadBalancer.ingress[0].ip} {.spec.rules[0].host}{end}'
これでingressで指定したホスト名指定でPCのブラウザからアクセスできる。
tag:minikube
さて、ingress経由でアクセスした掲示板に15MB程度のjpg画像をアップロードしようとしたら、nginxから怒られた；；
413 Request Entity Too Large nginx/1.13.7
対処は以下。client_max_body_sizeを設定するのが良いとのこと。
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server {
client_max_body_size 20M;
listen 80;
server_name localhost;
# Main location
location / {
proxy_pass http://127.0.0.1:8000/;
}
}
}
自分でnginxを立てている場合は↑で話は終わりだけど、minikubeのingressの設定は自動生成。 ということで設定方法が違う。
現在のIngressの設定（内部のnginxの設定ファイル）を表示する。
function f_minikube_ingress_conf_show() {
# Git-Bashだとパラメータの/etc/nginx/nginx.confに対して無駄なパス書き換えが起きる；；
# このため、 etc/nginx/nginx.conf と記載
# ingressのnginx.confを表示。
local NAMESPACE="kube-system"
local PODNAME=$( kubectl get pod --namespace=kube-system | grep nginx-ingress-controller | awk '{print $1}' )
kubectl -n $NAMESPACE exec $PODNAME -- cat etc/nginx/nginx.conf
}
f_minikube_ingress_conf_show
nginxの設定ファイルはえらく高機能なので、それを自動生成しようとなるとパラメータが大量に出てくる。以下を参照。
今回はannotationで設定する方法を選択。
Ingressのmetadata.annotationsの所に記載する。
設定例。
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: kjwikigdocker
annotations:
# for accept large file post
# see https://github.com/kubernetes/ingress-nginx
# see https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/annotations.md
nginx.ingress.kubernetes.io/proxy-body-size: 1560m
labels:
app: kjwikigdocker
spec:
rules:
- host: kjwikigdocker.minikube.local
http:
paths:
- path: /
backend:
serviceName: kjwikigdocker
servicePort: 8080
上の設定をkubectl apply -f <ファイル名>で適用。
設定変更後。現在のIngressの設定（内部のnginxの設定）を表示する。
# 上で定義したシェル関数を実行 f_minikube_ingress_conf_show
おお。ちゃんとIngressのnginxの設定が書き換わった。
大きなファイルのアップロードも成功。
んんん。Kubernetesって楽するためにえらく苦労してる感あるｗｗ
今のところ、3/1 AM 6:00 ごろ 南南西の風、風速35ｍという話なので京葉線はもう運転見合わせ確定も同然だが、はてさて。
後日談。
結局、5分くらいの遅延で普通に運行してたよ...。