2019年 04月の投稿を表示しています

needs-restarting

某所の某 CentOS7 なサーバー、たまに何も考えずにログインしては yum update -y して、更にたまに reboot してるけどこれもはや cron で自動でよいのではと思ったのでそうする。

そういえば、アップデート内容によっては再起動が必要かを調べてくれるツールがあったなあぼんやり思い出した。
調べてみたら needs-restarting だった。そのままだ。

yum-utils に入っているらしいので、それでいれる。

$ sudo yum search needs-restarting
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
...
============================================================================================================= Matched: needs-restarting =============================================================================================================
dnf-plugins-core.noarch : Core Plugins for DNF
python2-dnf-plugins-core.noarch : Core Plugins for DNF
yum-utils.noarch : Utilities based around the yum package manager

$ sudo yum install yum-utils
...
$ needs-restarting --help
Usage:
    needs-restarting: Report a list of process ids of programs that started
                    running before they or some component they use were updated.

Options:
  -h, --help        show this help message and exit
  -u, --useronly    show processes for my userid only
  -r, --reboothint  only report whether a full reboot is required (returns 1)
                    or not (returns 0)
  -s, --services    list the affected systemd services only

フルリブートが必要なのか、特定のサービスだけでいいのか、をオプションで切り替えられる模様。

こうしておいた。

$ cat /etc/cron.daily/yum
#!/bin/sh
yum update -y

$ cat /etc/cron.daily/needs-restarting-reboothint
#!/bin/sh
needs-restarting --reboothint

$ cat /etc/cron.daily/needs-restarting-services
#!/bin/sh
needs-restarting --services

確認した結果、全自動で再起動するようにしてもいいけど、何かが何かに引っかかって立ち上がらなくなったりして、まったく気付かないというのは少し怖いので、とりあえずは通知するだけにしておく。
cron はすでに通知…、というか MAILTO にかかれていて、本文に色々書かれていたので、このままで OK ということにしておく。

Kubernetes の Liveness と Readiness

簡単にまとめると Liveness に失敗したらザキ Readiness に失敗したらやけつく息。…いや逆にわからんような気もする。

Liveness は Pod が稼働できるかどうかの判定をする。判定に失敗した場合は Kubernetes がその Pod を作り直す。
Pod が提供するべき最低限の機能すら提供できない場合にこのチェックを失敗させるべきだろう。
たとえば自分のアプリケーションが待ち受けるサーバーを提供するんだけど、そこへの疎通が一切できないとか。それが最初から起きるならアプリケーションは起動しないだろうが、起動してから何かしらの理由でサーバが落ちるといったことが無いわけではないはず。

Readiness は Pod と疎通できるかの判定をする。判定に失敗すると Kubernetes が Service から切り離す。このとき Pod は生きたままになる。
デッカい初期データを読み込むなどと起動に時間のかかるようなアプリケーションだったとき、アプリケーションは無事に起動する(=Liveness をパスできる)が、リクエストを受け付けることができないので、そういった場合は Readiness を設定して、Serviceから切り離されるべきだろう。

 

あと、他のアプリケーションに依存している部分を Liveness や Readiness には入れないほうがよいはず。
その確認をいれていると、回り回って全ての依存関係が全滅するとか Liveness / Readiness のデッドロックが起こってしまいそうな予感がする。

A は B への疎通確認を Liveness にいれて、 B は C への疎通確認を Liveness にいれて、としたときに、仮に C が何かの影響で疎通できないような状態になると B が作り直され A が作り直され、結局 A → B → C とつながった機能が提供できなくなる。

接続できるけど Unavailable な状態、 HTTP でいうと 5xx なステータスを、アプリケーションあるいはプロキシするサイドカーな何かで返すほうがよいのでは?
ほら nginx も upstream につながらなくなっても nginx は終了せずに「upstream に繋がらないけど」というエラーが出るじゃん?
これを各 Pod でもできるようにしたほうがいいと思うのよ。

 

Liveness も Readiness もどちらも、監視までの時間、監視する間隔、判定失敗とするまでの許容する失敗回数といったオプション値を設定できる。
このあたりは公式ドキュメントを見るとまとまってるのでこまかい話はそっちを見るようにしたらよい。
Configure Liveness and Readiness Probes - Kubernetes

それと Liveness も Readiness も、どちらも時間や間隔の調整は必要なものの、基本的にはヘビーな処理が発生しないようにする必要がある。
Liveness や Readiness のチェックでかかる負荷によって、自分自身をを失敗させる原因にならならないようにするために。

brew まとめて更新する

とりあえず更新するようの便利セット。 fish 使ってるので function にしてるけど単に alias でもよいとおもう。

function brews
  brew update
  brew upgrade
  brew cask upgrade
  brew cleanup
  brew doctor
end

話変わるけどこういうことやるとポータビリティ上がってよさそう。

brew list > brew-list.txt
brew cask list > brew-cask-list.txt
mas list > mas-list.txt

やってみた。

brew list

apr
apr-util
aspell
autoconf
bash-completion
brotli
c-ares
clang-format
composer
curl-openssl
fish
fontconfig
freetds
freetype
gd
gdbm
gettext
ghq
git
git-chglog
glib
glide
gmp
go
graphviz
gts
icu4c
jansson
jasper
jemalloc
jo
jpeg
jq
kubectx
kubernetes-cli
kubetail
libev
libevent
libffi
libiconv
libidn
libmetalink
libpng
libpq
libssh2
libtiff
libtool
libyaml
libzip
make
mas
mcrypt
mhash
mysql
netpbm
nghttp2
oniguruma
openldap
openssl
pcre
pcre2
peco
php@7.1
pkg-config
pv
python
python@2
readline
rtmpdump
socat
sphinx-doc
sqlite
sshfs
stern
telepresence
the_silver_searcher
tidy-html5
torsocks
trash
tree
unixodbc
watch
webp
xz

brew cask list

charles
clipy
docker
firefox
goland
google-chrome
google-cloud-sdk
iterm2
java
minikube
osxfuse
phpstorm
sequel-pro
slack
station
visual-studio-code

mas list

540348655 Monosnap (3.5.7)
682658836 GarageBand (10.3.2)
408981434 iMovie (10.1.11)
409201541 Pages (8.0)
409183694 Keynote (9.0.1)
539883307 LINE (5.15.0)
409203825 Numbers (6.0)

なるたけ brew に載っておくと管理がお手軽でいいよ、と聞いてからできるだけ移した。

語彙崩壊してる