2017-12-26

12年SIerに居たのでおさらいでも。

どうも、SIerで12年ほど塩漬けになっているエンジニア風の人です。

もうこの業界に足を突っ込んで12年近く経ってしまったので、何をやってきたかのおさらいでも…

やってきたこと

・データセンターのオペレータ

ただひたすら手順書に沿って時間になったら監視、時間になったら監視…
エラーメッセージが出たら手順書見て一次切り分け、二次対応者にエスカレーション…という現場です。
オペレータはノースキルから入るには打ってつけの現場です。ITILで言うサービスデスクの領域を広く浅く実践できます。
シフト制かつ現場によっては24時間交代制とかなので体力的にも睡眠サイクル的にもタフでないと長続きしません。(私は長続きしませんでした)
運用現場の過酷さと(主に開発チームから引き継がれた中途半端なリリースを人力カバーするという)不条理さをこの時代に味わってなければ、後に運用のしやすいシステムとはどういうものかを都度考えることもなかったのかも知れません。

・社内システムの運用

社員数が数万人規模の現場だったので、社内システムの運用保全も楽ではありません。
人事異動は年間数千人規模、社内端末の異動も年に1000件は下りません。
(もちろん構成管理の自動化はしていましたが、当時自動化できない業務もいっぱいあります)
また、色々な部門から色々なアプリを使いたい！と検証依頼が押し寄せてきます。
検証対象アプリをインストールするとライブラリが更新される等の理由で既存アプリが動作しなくなることもあるため、検証は慎重に行う必要があります。
他にも業務サーバのアクセス権管理とかセキュリティパッチの配布からシステム運営予算の要求、システム監査の対応まで、割と何でも屋状態で時間が光の速さで過ぎていきました。

・あるシステム専任の開発と運用

あるシステムで使用する法人間WANのネットワーク設計、セキュリティ設計とかQA、運用設計をずっとやっていました。
オンプレ環境なので、データセンター側との電源容量や搭載ラック、搬入計画の調整や、通信事業者側とネットワークの敷設調整などもやります。
プロジェクトマネージャ的な立ち位置も兼ねていたので、ここでも割と何でも屋状態で時間が光の速さで(ry
さらに自分で設計したものを後に自分で運用サイクル回すという「変な設計したら自分が死ぬ」という環境だったので、運用設計の仕事にハリが出て仕方ありませんでした。

・資格

応用情報技術者、プロジェクトマネージャ、ネットワークスペシャリスト、情報処理安全確保支援士(登録済み)を取得しました。

私はそれぞれ経験した仕事を通じて「どこでも潰しが利く一般的な知識を得られているか」という確認テストの意味合いで、主に情報処理技術者試験を受験しています。
情報処理技術者試験(特に高度試験)は、実装能力や設計能力をストレートに問われるベンダー試験と違って「ダメな現場を改善するビフォーアフター」を広く一般的な知識を使って紐解くための経験と思考を問われているように感じます。
また、第三者が定義する知識レベルに達していることを試験を通して認定してもらう、という側面もあるため、「自称プロマネできます！」より「プロマネできます。プロマネ試験合格してます」のほうが経験の裏付けができるかなぁ、とも思っています。

おさらいしてみた感想

中途半端に器用貧乏すぎるorz
どこに向かえばいいんですかね。

「ひとりで何でもできるエンジニア」は勝手に育つ:Geekなぺーじ

フルスタックどころかクォータースタックにもなってないと自分では感じてます。

2017-12-15

(仮復旧?)うちのインスタンスがしばらくすると502エラーになる件

surdon.hateblo.jp

前回のエントリの続きです。

結果的にdocker-ce を17.09に戻したら安定稼働するようになりました…

前回のエントリーの後も何度かdockerがクラッシュしてシステムごと再起動したりしてました。

クラッシュする時の挙動は「fatal error: concurrent map writes→コンテナ自動kill&restart→実はrestartできていない→コンテナ間socket通信失敗→fatal error: concurrent map writes→以下エンドレス」みたいな感じ。

dockerd自体がクラッシュするのがとても気になっていたので、docker-ceの変更履歴を読んでみました。

github.com

IMPORTANT: Docker CE 17.11 is the first Docker release based on containerd 1.0 beta. Docker CE 17.11 and later won't recognize containers started with previous Docker versions. If using Live Restore, you must stop all containers before upgrading to Docker CE 17.11. If you don't, any containers started by Docker versions that predate 17.11 won't be recognized by Docker after the upgrade and will keep running, un-managed, on the system.

[google翻訳]

重要：Docker CE 17.11は、containerd 1.0 betaを採用した初めてのDockerリリースです。 Docker CE 17.11以降では、以前のDockerバージョンで起動したコンテナは認識されません。ライブリストアを使用する場合は、Docker CE 17.11にアップグレードする前にすべてのコンテナを停止する必要があります。そうしないと、17.11より前のバージョンのDockerで起動されたコンテナは、アップグレード後にDockerによって認識されず、システム上で管理されずに実行され続けます。

ひょっとして：docker-ce 17.11環境でコンテナ再構築しないといけない

www.publickey1.jp17.11からdocker-ceの仕様変わってんじゃん。

google先生に教えてもらった別のコンテナに関するQAで「docker-ce 17.11でクラッシュするが17.09にダウングレードしたら再現しなくなった」ぽい書き込みがあったので、docker-ceを試しに17.09にダウングレードしてみる。

※書き込みのソースどこだったか忘れました。思い出したら後日リンク貼ります…

# yum remove docker-ce.x86_64

# yum --showduplicate list docker-ce.x86_64

docker-ce.x86_64 17.09.1.ce-1.el7.centos docker-ce-stable
docker-ce.x86_64 17.10.0.ce-1.el7.centos docker-ce-edge
docker-ce.x86_64 17.11.0.ce-1.el7.centos docker-ce-edge

→docker-ce-stableな17.09.1を入れ直すことにする

# vi /etc/yum.repos.d/docker-ce.repo

docker-ce-edgeのenablerepo=0に変更

# yum install docker-ce.x86_64

Installing:
docker-ce x86_64 17.09.1.ce-1.el7.centos docker-ce-stable 21 M

→17.09.1が選択された

# systemctl start docker

# docker version

Client:
Version: 17.09.1-ce
API version: 1.32
Go version: go1.8.3
Git commit: 19e2cf6
Built: Thu Dec 7 22:23:40 2017
OS/Arch: linux/amd64

Server:
Version: 17.09.1-ce
API version: 1.32 (minimum version 1.12)
Go version: go1.8.3
Git commit: 19e2cf6
Built: Thu Dec 7 22:25:03 2017
OS/Arch: linux/amd64
Experimental: false

最後にdocker-composeでmastodonのコンテナ達を停止→再起動

とりあえず再起動から2日経ちましたが特に問題なく稼働しているようです。

/var/log/messagesにもdockedからほとんどエラーログを吐かなくなりました。

根本原因がここかどうかは自分でもわかってないので、モヤモヤしつつも稼働状態を注視していきたいと思います。

ちなみに

github.com前回エントリでリンクしたmoby/mobyでの議論に更新があり、「17.12(現時点ではRC1)で本事象は解決した」とのことです。

とりあえずstableな17.09で様子見ます。

教訓

docker-ce-edgeを闇雲に攻めないようにしよう。

あと、変更履歴って大事。

2017-12-07

うちのインスタンスがしばらくすると502エラーになる件

Mastodon

引きこもりMastodon、なぜか起動してしばらくたつと"502 Bad Gateway"になってしまいます。

f:id:surdon:20171207100936p:plain

前回再起動時に事前に下記コマンドでdockerコンテナログを全部クリアしていたので、実質起動直後から今までのログが溜まっている状態です。

$ sudo truncate -s 0 /var/lib/docker/containers/*/*-json.log

web_1コンテナの最後のログが、

web_1	[10] ! Out-of-sync worker list, no 20 worker
web_1	[10] - Worker 0 (pid: 1361) booted, phase: 0

pumaがエラーになったあと再起動したようなログっぽく見える。(結果的に再起動できてないから502エラーになっている？)

docker-compose stopしてもいくつかのコンテナからエラーが出て停止できなくなってしまいました。

$ docker-compose stop
Stopping mastodon_web_1 ...
Stopping mastodon_streaming_1 ...
Stopping mastodon_sidekiq_1 ... error
Stopping mastodon_redis_1 ... error
Stopping mastodon_db_1 ... error

ERROR: for mastodon_sidekiq_1 cannot stop container: f444c(略): Cannot kill container f444c(略): process f444c(略) not found: not found

ERROR: for mastodon_streaming_1 UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=70)

ERROR: for mastodon_web_1 UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=70)
ERROR: An HTTP request took too long to complete. Retry with --verbose to obtain debug information.
If you encounter this issue regularly because of slow network conditions, consider setting COMPOSE_HTTP_TIMEOUT to a higher value (current value: 60).
$

そしてこの後なぜかサーバインスタンスごとクラッシュ…(ssh接続不能)

サーバインスタンスをVPSコントロールパネルから再起動して、/var/log/messagesも確認。そしたら

Dec 7 06:07:01 dockerd: fatal error: concurrent map writes
Dec 7 06:07:01 systemd: docker.service: main process exited, code=exited, status=2/INVALIDARGUMENT
Dec 7 06:07:01 systemd: Unit docker.service entered failed state.
Dec 7 06:07:01 systemd: docker.service failed.
Dec 7 06:07:01 systemd: docker.service holdoff time over, scheduling restart.
Dec 7 06:07:01 systemd: Starting Docker Application Container Engine...
Dec 7 06:07:03 systemd: Started Docker Application Container Engine.

※だいぶ中間省略してます。実際は最初と最後の間にdockerdから1400行近くメッセージ出てます。

キーワードでググると下記Issueがヒット。

github.com

ん？ひょっとしてDocker自体がクラッシュしてる？

docker-compose stop投入後OSに接続できなくなった直前、

Dec 7 10:43:39 kernel: Out of memory: Kill process 709 (dhclient) score 3 or sacrifice child
Dec 7 10:43:39 kernel: Killed process 709 (dhclient) total-vm:113372kB, anon-rss:44kB, file-rss:0kB, shmem-rss:0kB

なぜかメモリ不足？でDHCPクライアントも異常終了してしまったようです。

サーバインスタンス再起動後、systemctl restart dockerするとMastodonコンテナが自動起動して一旦仮復旧。(まだ根本解決には至っていないけど)

一応Docker環境のバージョンメモ。

# docker version
Client:
Version: 17.11.0-ce
API version: 1.34
Go version: go1.8.3
Git commit: 1caf76c
Built: Mon Nov 20 18:35:47 2017
OS/Arch: linux/amd64

Server:
Version: 17.11.0-ce
API version: 1.34 (minimum version 1.12)
Go version: go1.8.3
Git commit: 1caf76c
Built: Mon Nov 20 18:45:06 2017
OS/Arch: linux/amd64
Experimental: false

# docker-compose -v
docker-compose version 1.15.0, build e12f3b9

# docker info
Containers: 5
Running: 5
Paused: 0
Stopped: 0
Images: 53
Server Version: 17.11.0-ce
Storage Driver: overlay
Backing Filesystem: extfs
Supports d_type: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 992280e8e265f491f7a624ab82f3e238be086e49
runc version: 0351df1c5a66838d0c392b4ac4cf9450de844e2d
init version: 949e6fa
Security Options:
seccomp
Profile: default
Kernel Version: 3.10.0-693.5.2.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 3
Total Memory: 1.953GiB
Name: (略)
ID: CXM4:HECZ:HVNH:(略)
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false