CKS受験したら色々とトラブルが発生した話
はじめに
n年ぶりの記事更新。
インフラエンジニアになってからなんだかんだで4年ほど経過しました。
最近会社からはAWSの資格取得が激推しされる中、1年前に購入したCKSバウチャーの期限が迫っていたので先日受験してきました。
初回受験時に色々トラブルがあり、思うような結果は残せませんでしたが
この記事が今後受験する方々の礎になればと思います。
受験準備
使用した教材
- Udemyの講座
カリキュラムの解説動画、2回分の模擬試験がついてきます。
この模擬試験は実際の環境とほぼ同じ環境で問題を解くことが出来るので、試験前に必ず解いておいた方が良いです。
問題の内容はかなり難しいので、出来なくても気にせず復習を念頭に進めましょう。解き方を覚えていけば実際の試験で役に立ちます。 - Killercoda
CKSカリキュラムの練習問題に取り組むことが出来ます。
上記のUdemy講座の中ではレクチャーの最後に確認問題として出てきますが、これ単体でも無料でチャレンジすることが出来ます。 -
Docker/Kubernetes開発・運用のためのセキュリティ実践ガイド (Compass Booksシリーズ)
Udemy講座はすべて英語なので、動画を見ただけでは理解できなかった部分などを補助するために購入しました。
https://amzn.asia/d/dTjJugL
CKSの対策用という主旨の本ではないのでカリキュラムに沿った形で書かれているわけではありません。
が、内容的にはUdemyで解説している分野に関して触れている部分が多いため、動画を見て理解できなかった部分を目次や索引から探してみて説明を読む、というような使い方をしていました。
勉強期間
バウチャーを購入してから1年近く他の試験と並行してダラダラと勉強をしていたのですが、期限が迫ってきてしまったということで身を入れてしっかり勉強したのは2～3週間程度でした。
リテイクポリシーが1回あるので、バウチャー期限1か月前から試験スケジュールを立て、1回目の受験は2週間勉強して力試し的に受け、その後試験の結果を受けて2週間後の2回目で受かるつもりで考えていました。
その他試験環境の準備
3年前くらいにCKAを受けており、その時のことを思い出しつつ
直近試験環境がだいぶ変わったという話は聞いていたので、
他の方の準備記事などを確認しながら以下の準備をしました。
- 試験会場
- 近くの貸し会議室を借りました。試験官によるかなり厳しいチェックがあるとのことだったので、完全個室で使えるところ、音なども気にならないような場所を選びました。
- ディスプレイ
- 新しい試験では、PSIが用意する試験専用のセキュアブラウザを利用するとのことだったのですが、様々な受験体験記事で「リモデ環境でドキュメントやターミナルを開き作業を行うので、大きなディスプレイが必須」ということが書かれていたので自宅で使っているディスプレイを会場に持ち込みました。（結構大変だったので試験会場で据え付けのところを選んだ方が良かったかも？）
- 身分証明書
- 前回受けた時と同様にマイナンバーカードを用意、何かあったときの予備として運転免許証も持っていきました。
同僚が今年CKAを受験し、リモデ環境のレスポンスが非常に悪く試験にならなかった、という話を聞いていたので、念のため受験前にインターネット速度のチェックをしておきました。
といっても、試験会場として選んだ会議室はWi-fiが弱く、速度診断としては「低速」と出てしまったのですが。。下り20～30Mbpsくらいだったと思います。
しかし、ローカルブラウザでは問題なくサイト閲覧ができる状態で、他のアプリを使っていても遅延していると感じることは無かったので、まあ大丈夫だろくらいの気持ちで受験を開始しました。
受験時のトラブル
身分証明書の表記と受験登録時の名前が一致しない
これは完全に私の確認ミスが悪いのですが、Linux Foundationで受験時の名前をローマ字で登録しており、身分証明書として提示したマイナンバーカードや運転免許証では漢字表記だったため、身分証明として受け付けることが出来ない、と言われてしまいました。
以前CKAを受けたときはクレジットカードとマイナンバーカードを提示すればローマ字でも身分証明として受け付けてもらえたので、今回も同じようにやったら「クレジットカードは身分証明書として認めない、これ以上対応してほしいならテクニカルサポートに電話してほしい」と言われてしまいました。
国際電話できない＆英語話せないのでパニクッていたところ
埒が明かないと思われたのかそのままセキュアブラウザのセッションが閉じられ、試験後のアンケートが表示されました。。
さすがに何もしないまま1回目が終わってしまうのは納得いかないので、Linux Foundationのマイページに行き、Settings＞BASIC INFORMATIONで本名を漢字で登録しなおし、再度セキュアブラウザから受験準備を進めました。
本来は上記のスクリーンショットの通り、試験ダッシュボードからVerify Nameを登録し直す必要があったと思うのですが、その時は何とか通してもらい、無事試験を開始することが出来ました。
試験のリモートデスクトップ接続のレスポンス遅延
これは前述している通り一応事前に情報は入っていたのですが、予想以上に遅延がひどかったです。
udemyの講座についてくる模擬試験を受けると受験時と同じような環境を体験することが出来ますが、模擬試験時にはリモートデスクトップ環境の遅延はほとんど感じませんでした。
しかし、実際の試験の環境ではリモートデスクトップ環境の遅延が激しく、
最初は少しもっさりしているかな？くらいの感覚だったのですが
時間が経過するにつれて遅延がひどくなっていきました。
時間が半分ほど経過した時点で、1つの操作に対するレスポンスが10秒以上かかる状態になってしまい、イライラしながら受験していたら試験官から「よそ見しないでください。試験中止を言い渡す可能性もあります」と言われ、さらにイライラ。
結局遅延のせいで1/3もまともに問題を解くことが出来ず、2時間の試験が終了しました。
結果
1回目の試験は上記のような状態だったため、散々な結果でした。
半額バウチャーを使ったとはいえ、一般的なIT資格より非常に高額な料金を支払って受験しているので、文句を言いたい気持ちでいっぱいでした。
同じような状況だった人はいないかという記事を探したところ、2022年の記事が見つかりました。
上記の記事の方は大阪で受験したとのことですが、私は埼玉で受験しました。
以下のLFの記事では受験予約で指定したリージョンでリモデ環境が構築されるようにネットワーク遅延の問題が修正されたと記載されていますが、本当に修正されたのか？と思うくらいの遅延でした。
「受験者の環境を揃えることで公平性を保つ」という理由で新しいプラットフォームにしたはずなのに、地域によって受験環境に差分が出るのはどうなんでしょうか。
受験する地域やネットワークの速度によってここまで受験環境に差分が出ることが懸念されるなら、受験前のPCでの環境チェックでそこまで確認できるようにするか、そもそも日本での受験を受け入れること自体やめる方が誠意のある対応なのではと思いました。（これらのクレームはアンケートに記載しました）
2回目の受験
1回目で散々な目に合ったのでやる気をなくしてしまい、まだバウチャー期限まで2週間ありましたが1週間後に再受験することにしました。
2回目は前回の対策も踏まえて以下の環境で受験することにしました。
- 自宅で受験
- 田舎なので近くに貸会議室が少なかったことや、貸会議室のネットワーク速度を事前に知ることは難しいと思い、自宅で受験することにしました。
- 自宅では事前にネットワーク速度を確認したところ、以下のような結果でした。
- 受験時間を早朝（6:00）に設定
- ネットワーク遅延を少しでも減らすために混雑しないような時間にしました。
これらの対策をしても遅延が改善されない場合、私も上記の記事の方と同様にクレームを入れて返金してもらおうと思っていました。
2回目の受験前のチェック（身分証明、試験環境チェック）は1回目の反省が活きたのか、比較的スムーズに受験開始することが出来ました。
自宅で受験する場合、デスク回りを極力何もない状態にしておくことをお勧めします。
私はディスプレイ、外付けキーボード、マウス、PCだけの状態にしましたが、
普段電源タップをくっつけているマジックテープやコードクリップに異様に食いつかれました。（結局マジックテープは剥がせといわれました。。粘着式だったので剥がすのが大変でした）
そしてとうとう2回目の試験が開始され、肝心の遅延はというと・・・
1回目よりは断然マシ、という感じでした。
やはり時間経過と共にレスポンスは遅くなっていくと感じたのですが、Wi-fi速度が1回目の2倍くらい早いため1回目ほどひどい遅延は感じませんでした。最後らへんになってレスポンスに２～３秒かかるくらい。
また、問題の内容について大半は1回目とほぼ同じ問題が出題されました。
1回目は遅延のせいで一挙一動に時間がかかってしまうため、最低限の回答操作だけ行うことに精一杯で確認までできなかったのですが、2回目は一応全ての問題に目を通し、回答した問題の確認もすることが出来ました。
まとめ
結局、2回目の受験も10%程度合格ラインまで足りず不合格でした。
が、一応2回目は回答に大幅に支障が出るほどの影響は及ぼされなかったと感じたため、直接クレームの問い合わせは入れませんでした。
正直言って受験前の準備コストも含めて疲れてしまったしもういいか、というのが本音ですが。。
不合格という結果になってしまいましたが、試験内容は普段の業務にも生かせそうですし、勉強してよかったと思っています。
再試験については受験費用が非常に高額なので、一旦他の試験などで気晴らししてからまた気が向いたらしようかと思っています。
長々と書きましたが、これから受験しようと思っている方の助けになれば幸いです。
udemy Certified Kubernetes Administrator (CKA) with Practice Tests の癖あり問題
はじめに
あけましておめでとうございます。
今年もよろしくお願いいたします。
先日、なんとかCKAに合格することができました。
1年間CKA合格のために勉強をしてきましたが、その時主に利用してきた教材が、
udemyの「Certified Kubernetes Administrator (CKA) with Practice Tests」という講義です。
こちらはCKAを受けるに当たってとても良い教材なので（practiceで手を動かして覚えることができる、MockExamの内容が実試験に即していて良い）
受験予定の方にはオススメしたいのですが、中には練習問題や模擬試験の回答通りにコマンドを実行しても正解の判定がもらえない問題があります。
今回はそのような問題について、正解判定をもらうことができた回答を書いていきたいと思います。
癖あり問題-MOCK EXAM02-Q7
【問題内容】
nginxのpodとそのpodに結びついたserviceを作成し、名前解決用のpodを作成して名前解決結果をファイルに書き込みなさい。
問題内容は少し要約してます。
こちら、前半のpod,service作成の部分はSolutionの動画を見ることで問題なく作成することができますが、
名前解決部分に割と癖があり、Solutionのやり方をそのままやってもpodが動かなかったりします。
【Solutionの回答】
#podの作成（--generatorオプションは現verでは必要なくなっている為省いています） controlplane $ kubectl run nginx-resolver --image=nginx pod/nginx-resolver created #確認 controlplane $ kubectl get pod NAME READY STATUS RESTARTS AGE nginx-resolver 1/1 Running 0 14s #service expose controlplane $ kubectl expose pod nginx-resolver --name=nginx-resolver-service --port=80 --target-port=80 --type=ClusterIP service/nginx-resolver-service exposed #確認 controlplane $ kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 11m nginx-resolver-service ClusterIP 10.103.204.143 <none> 80/TCP 8s #名前解決確認用pod作成/コマンド入力 controlplane $ kubectl run test-nslookup --image=busybox:1.28 --rm -it -- nslookup nginx-resolver-service
名前解決確認用pod作成/コマンド入力のコマンドをそのまま入力するとプロンプトが返ってこず、
ctrl+Cで強制的に中断することになります。
kubectl get pod でステータスを確認すると、以下のように遷移していることがわかります。
また、logsでpodのログを確認するとnslookupの回答は返ってきている為、名前解決コマンドには問題なさそうです。
controlplane $ kc get pod NAME READY STATUS RESTARTS AGE nginx-resolver 1/1 Running 0 4m57s test-nslookup 0/1 ContainerCreating 0 11s controlplane $ kc get pod NAME READY STATUS RESTARTS AGE nginx-resolver 1/1 Running 0 5m1s test-nslookup 0/1 Completed 1 15s controlplane $ kc get pod NAME READY STATUS RESTARTS AGE nginx-resolver 1/1 Running 0 5m6s test-nslookup 0/1 CrashLoopBackOff 1 20s controlplane $ kc logs test-nslookup Server: 10.96.0.10 Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local Name: nginx-resolver-service Address 1: 10.107.253.197 nginx-resolver-service.default.svc.cluster.local
名前解決確認用pod作成/コマンド入力に「--restart=Never」というオプションを付与して実行すると、正しく名前解決結果が標準出力に出力されます。
【回答】
controlplane $ kc run test-nslookup --image=busybox:1.28 --rm -it --restart=Never -- nslookup nginx-resolver-service Server: 10.96.0.10 Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local Name: nginx-resolver-service Address 1: 10.107.253.197 nginx-resolver-service.default.svc.cluster.local pod "test-nslookup" deleted controlplane $
Solutionの回答通りのコマンドの場合、restart policyというPodの再起動の挙動を決めるパラメータがデフォルトのAlwaysになってしまい、
podがコマンドの成功失敗に限らず再起動を繰り返す為、--rmオプション（コマンド実行後podを削除する）との親和性が取れず上記のような挙動になってしまったのではないかと考えられます。
（practiceやMock Examで利用するkatakodaの仮装環境のバージョンは逐次最新に更新されているようなのですが、解答動画はあまり更新されていないようなので
解答動画の環境と実際の作業環境が噛み合っていないようです。以前のバージョンの環境では解答動画の通りでも出来たのかもしれないですね。）
kubectl runのオプションについてはこちらを参照（公式）
kubernetes.io
kubectl runについて日本語で説明してくれている記事はこちら
qiita.com
ちなみに、podの方のコマンドもそのまま実行するとプロンプトが返ってこなくなります。
以下で実行すると標準出力が正常に行われます。
controlplane $ kc get pod -owide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-resolver 1/1 Running 0 70m 10.244.1.3 node01 <none> <none> controlplane $ kc run test-nslookup --image=busybox:1.28 --rm -it --restart=Never -- nslookup 10-244-1-3.default.pod Server: 10.96.0.10 Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local Name: 10-244-1-3.default.pod Address 1: 10.244.1.3 10-244-1-3.nginx-resolver-service.default.svc.cluster.local pod "test-nslookup" deleted controlplane $
おまけ
MOCK EXAM02-Q8でnode01にstatic podを作成せよという問題がでますが、
node01でkubectlを実行しようとすると以下のようなエラーが出ます。
node01 $ kubectl get pod The connection to the server localhost:8080 was refused - did you specify the right host or port?
kubeconfigの仕組みをちゃんと理解していれば全然引っかからないところなのですが、
1回目の試験前に勉強した時は「なんでkubectl実行できないの！？」ってなっていたので一応恥を忍んで書いておきます。(笑)
これはkubeconfigがnode01に配置されていない為出てしまうエラーです。
以下のコマンドでcontrolplaneと同じkubeconfigファイルをnode01に配置しましょう。
controlplane $ scp .kube/config node01:/root/ Warning: Permanently added 'node01,172.17.0.25' (ECDSA) to the list of known hosts. config 100% 5567 5.9MB/s 00:00 controlplane $ controlplane $ ssh node01 root@node01:~# root@node01:~# kubectl get node The connection to the server localhost:8080 was refused - did you specify the right host or port? root@node01:~# mkdir .kube root@node01:~# mv config .kube/ root@node01:~# root@node01:~# kubectl get node NAME STATUS ROLES AGE VERSION controlplane Ready master 11m v1.19.0 node01 Ready <none> 11m v1.19.0 root@node01:~#
ちゃんとnode01にstatic podが作成されているかはcontrolplaneでも確認できるのですが、
戻って確認するのもめんどくさい、という方はこちらでnode01でも確認できるようにされてみては。
おしまい
2年目インフラエンジニアのCKA受験合格記
はじめに
こちらの記事はエーピーコミュニケーションズ Advent Calendar 2020 23日目の記事になります。
qiita.com
3ヶ月ぶりの更新です。
ブログの書き方も覚えているか微妙な中ですが、私がこの1年ほど勉強してきたCKAの受験記について
書いていこうと思います。
ちなみに、去年の12月頃から勉強を始めていますが、残念ながらまだ受かることができていません…。
ので、あくまで「合格記」ではなく「奮闘記」としています。
役に立つ記事になるかはわかりませんが、
- なんちゃって情報系からエンジニアになった社会人2年目（数理系激弱）
- CKA問題改訂前と改訂後を受験している
この二点の観点から勉強法やつまづいたこと、落ちてわかったことなどを書いていこうと思います。
これから受験する方の参考になれば幸いです。
追記：2020/12/29付でCKA合格しました。
記事の最後に3回目受験の体験も追記します。
勉強方法（1回目/CKA改訂前）
コンテナって何ですか？と言う状態からの開始でした。
具体的に対策として行ったのは以下になります。
- dockerの基礎から勉強する為にいわゆるくじら本と言われている参考書のハンズオン
- Mirantis KC-100（会社で受けさせてもらった）
内容的にはdocker,k8sの基本て言う感じです。
- 会社のdocker初級アカデミー
- udemyのCKA対策講座
本格的な勉強はudemyの講座を中心に勉強をすすめました。
こちらはplactice、模擬試験が優秀なので、とてもおすすめです。本当の試験に出てくる問題もかなりあります。
普通に買うと結構高いですがちょくちょくやっているセールで買うと1300円程度で購入できるので是非狙ってみてください！！
ただし、講座の動画は完全英語なので英語に馴染みがない方はみるのに骨がいるかもです・・・
1回目受験/結果/反省
■試験資格
去年のlinux foundationのサイバーマンデーで購入した無料バウチャーを使って受験しました。
金額はlinux foundationのトレーニング込みで、188.97$でした。（日本円で2万ちょい）
普通にこのコース（試験＋トレーニング）を買うと499$みたいです。
■試験日
本当は6月中旬に試験予約をしていましたが、linux foundationのメンテナンスに試験日が被ってしまい
ずれ込んで2020/06/27に受験しました。
問答無用で試験のキャンセルメールがきていました…先に言ってほしい…
■試験場所
場所は自社の会議室を借りました。
一度場所を借りたのに上記の通りlinux foundationのメンテナンスに被ってしまい、キャンセル料を徴収されてしまいました。。
完全個室の貸し会議室はそこそこ高いのに…先に言ってほしい…
■試験準備
試験に必要なもの、環境に関してはlinux foundationのダッシュボードからCertification > Resumeをクリックで
確認、準備ができます。
試験時に英語の名前と顔写真が確認できる証明書が必要なのでパスポート取らなきゃいけないか・・・？と
ヤキモキしていましたが、クレジットカードとマイナンバーカードでいけると言う話を聞いたので
特にこの辺は用意せずでした。
■試験当日
試験概要に書いてあるのもあると思いますが、一応気になったポイントを書いていこうと思います。
- 試験は3時間
- 透明の入れ物であれば飲み物を飲むことも可能。
- 公式ドキュメントを１タブ開くことができる
- 試験15分前にpsiの「My Exams」ページに「take exam」というボタンが出てくる。クリックするとページに飛ぶ。
- 試験前に画面共有、webカメラ・マイク共有・試験環境確認などの準備がある
- 英語の試験しか選べなくて心配だったけど結局日本語で受けれた（最初のチャットも依頼すれば日本語でしてくれる）
- 試験終了10分前にチャットで連絡くれる
- Lpicなどのように、解答したかどうかを一覧で見ることが出来ないので、解けた問題にフラグ立てておくと良さそう。
- 問題ごとにcontextを変更する必要があった
3時間ぶっ通しで頭を使いまくって頭痛がする中終わりました。。。
考えている時間より、手を動かしている時間の方が圧倒的に多かったです。ていうか考えている暇がない・・・
■試験結果
3日後くらいにメールで結果が届き、残念ながら64%でfailedでした。
合格ラインは74%でした。
勉強方法（2回目/CKA改訂後）
2回目は1回目の試験の手応え、結果からわからなかった問題の解き方と、
基礎的なリソースの学び直しということで完全ガイドを読みつつ理解を深めました。
udemyは先に行った通り講座は全て英語なので、英語を大学受験以降ちゃんとやっていなかった私としては
日本語のしっかりしたテキストは非常に助かりました。
完全ガイドは全くの初心者の方には詳しすぎるため、情報の取捨選択をできるくらいに勉強したタイミングで
読み始めるのが良いかもしれません。
- udemyのCKA対策講座
- kubernetes完全ガイド
2回目受験/結果/反省
■試験資格
最初に購入したバウチャーの再試験資格を使って受験しました。
再受験の方法がパッとわからず地味に詰まっていたのですが、意外と書いている方が少なく・・・
やり方がわかったらすんなり行けたので、書いておきます。
linux foundationのダッシュボードのcertification > Resume
左のmenuのドロップダウンから「exam」を選ぶと再試験のスケジューリングができるようになります。
最初linux foundationのダッシュボードを全然使わず、psiでだけやるものだと思っていたので
再試験の予定ができず困っていました・・・
■試験日
2020/10/31に受験しました。
■試験場所
1回目と同じく自社の会議室を借りて受験しました。
■試験準備
1回目と特に変わらず。
■試験当日
例によって箇条書きで気になったことを。
- 試験時間は2時間
→特にこだわりない人は複数ブラウザダウンロードしておいた方がいいかも？
- 何か怪しいものがないか確認されるが、モニターやホワイトボード、プラスチックパーテーション等は特に指摘されない
- 一定時間ごとに手をあげてくださいという指示がきます、カンニング防止？
■試験結果
シルバーウィークと被ったからなのか、結果が出るまでに2週間ほど時間がかかりました。
結果はなんと合格ライン66%中19%でfailed。。。
個人的にかなり手応えがあったつもりだったので残念でした。
■反省
思ったより全然できていなかったことの理由をいろいろ考えましたが、
一番は分野の採点基準が変わったことかなと思います。（トラブルシュート系の問題の配点が30％も占めるようになった）
あとは試験時間が2時間に減ったのに問題数と１問のボリューム感があまり減っていないことで
結構焦ってケアレスミスがあったのかなーというところですね。
試験問題改訂前よりもコマンド一つ一つに求められる速さが早くなっている気がしました。
細かく時間を削れるので、やっぱりコマンド慣れしておくこと、略称を覚えておくこと、エイリアスをうまく使うこと（defaultネームスペース以外での作業がメインになる問題は、エイリアスをkubectl -n namespaceで登録しておくと楽です）が重要だと感じました。
振り返り/これからの受験に向けて
1年ほどのんびりCKAを受験してきて、学んだことやよかったなということを箇条書きにしていきたいと思います。
- udemyの講座は買って本当によかった。テキストをただ読むのが苦手なので、ハンズオンがあると手が覚えるのでとてもよかったです
問題内容も試験内容に直結するものが多かったのでこれは本当にお勧めです。
- kubernetes.ioのドキュメントは一通り確認して、よく使うページはブックマークしておきましょう。（当日はkubernetes.ioであればブックマークから飛んでも怒られなさそうです）
- 勉強以外の準備が意外と必要な場合がある（顔写真つき証明書の用意や会議室の用意など）
- 結構シビアな試験。完全なハンズオン形式なので手の速さは絶対あった方がいい
→ぺーぺーエンジニアだったのでNWやサーバーの基礎知識がなく、そう言った点で試験中困ることもわりとありました。
コマンド等滑らかに打てた方がいいので、Lpic level1くらいは事前知識としてあった方がいいかも
- 試験中に使うマニフェストは絶対公式からコピーか、dry-runで作成したものを公式ドキュメントを参考に編集していく方法が良いと思います。
インデントやスペルミスでハマるのはとてももったいない・・・
実は今週の日曜にまた受験予定なので、頑張ってきたいと思います。
３度目の正直…！
今回は時間がなく書けませんでしたが、受かった後にudemyの問題のクセ（一部解けない問題がある）の記事など書いてみたいと思っています。
ここまで読んでいただきありがとうございました。
ここから追記：
勉強方法（3回目/CKA改訂後）
3回目は問題の傾向や基本のリソース、コマンド等は押さえていたため
2回目の試験で答えられなかった苦手問題のリソースについて公式ドキュメント・完全ガイドで復習しつつ
udemyの模擬試験を解いて回答作成のスピードを早めていくことに専念しました。
具体的に勉強しなおしたのは以下。
・Ingress
・NetworkPolicy
・etcd pod backup,restore
・side car container
・node trubleshoot
- udemyのCKA対策講座
3回目受験/結果/反省
■試験日
2020/12/27に受験しました。
■試験場所
年末だったりコロナだったりで外出が嫌だったので自宅の近所の会議室を借りました。
移動時間が少ないことは意外とストレスが軽減するものですね。
ギリギリまで勉強できますし。
■試験準備
1回目と特に変わらず。
■試験当日
基本は2回目と同じです。
- 試験時間は2時間
- 今回はキーボードを使用して受験してみました。特に問題なかったです。
- 前回は頻繁に「手をあげて」という指示をされましたが、今回は1回もされませんでした…試験官による？
- 初めてトイレ休憩を入れましたが特に問題なしでした。
- 今回は最後に時間の余裕があったので初めて見直しをすることができました。途中までですが…
■試験結果
36時間以内に結果が発表され合格でした！
やっと！CKA！受かりました！
— Mamekonb (@mamekonb) 2020年12月30日
３度目の正直！やったーーー！！ pic.twitter.com/NgHiQfR3vL
■反省
私は合格まで1年もかかってしまいましたが、もっとハイペースで受けることは全然可能だと思います。
試験問題の傾向を掴むこと、コマンドに慣れること、そして業務と並行して自主学習を続けるということの難しさで
ここまで時間がかかってしまいました…
（失格した後勉強のモチベーションを続かせるということの難しさも痛感しました…）
何はともあれ、今年中に合格することができて本当によかったです。
心残りなく歳を越せそうです。
来年も多くの資格を受けることになりそうなので、頑張りたいと思います…！
この体験記がこれからCKAを受験予定の方、未経験エンジニアでCKAを受験しようとしている方の
お役に立てば嬉しいです！
それではみなさん良いお年を！
久々に記事を書こうとしたらネタがない話
どうも、半年以上ぶりです。
久しぶりにブログでも書こうかなと思ったのですがまとまったネタがないので、
ここ最近やっていることとかを書こうかなと思います。
-
- -
この半年くらいでやったこと
■mirantisのKT-100を受講
会社のお金でmirantisのKT-100の研修を受けさせて頂きました。
もう半年くらい前なのであんまり覚えていないのですが、dockerのくじら本を中途半端にやったくらいのところで受けたので
半分くらい内容が理解できました。最後の試験はギリ失格でしたが、まあ学んだことは多かったので。。
くじら本途中でやめてしまいましたが時間あったら最後まで記事書きたい。
■udemyのCKA対策講座を受講
Certified Kubernetes Administrator (CKA) with Practice TestsというCKA対策用の講座を受講しました。
セールの時に購入してほったらかしにしてたのですが、そろそろ受けないとと思って
試験の3週間前くらいから本格的にやり始めました。
講義内容は全て英語で結構しんどかったのですが、practice handsonとmock examがとても役に立ちました。
テキスト読むと眠くなってしまう私としては実際に手を動かしてできるハンズオンがありがたかった！（実際英語の講義を子守唄に何度か寝た）
実際の試験問題にもかなり近く、CKAを受けようとしている方にはマジでおすすめです。
■CKAを受験（1回目）
6月下旬にCKAを受験しました。
結果から言うとギリ落ちたのですが、自分で思ったよりはできていて安心しました。
一回だけ再受験制度があるので（めちゃくちゃありがたい）、近いうちに再受験しようと思っています。
とは言いつつ、今月から試験内容が変わったみたいなのでまたudemyやり直しですね・・・
udemyはしっかり試験内容改訂にも対応しますと書いているので安心です。できれば、講義の日本語字幕もつけて欲しい。
CKAは2回目受けたタイミングで受かれば受験体験記書こうかなと思っています。
新卒のうちにCKA取りたかったー。。
■人生で初めて設計書を書く
業務で初設計をさせてもらいました。
キャリアやスキルレベルを問わず、様々なことにチャレンジさせてもらえる今の現場はとてもよい環境なのですが、
時に無茶振りと思われるようなレベルの高いタスクが振ってきたりもするので毎日ヒヤヒヤしています。
今回やったのはOracleDBの冗長化設計だったのですが、要件定義がだいぶフワフワしていたのでかなり苦労しました。
進め方がわからないとあんなにも仕事って嫌になるものなんですね。
ともあれ、なんとかまとまってよかったです。本当にまとまっているのか？
■人生で初めて引継ぎをする
こちらも業務ですが、春ごろにこれまでやってきた運用作業を他のチームの方に引き継ぐ必要があり、
これまでなんとなくやっていた作業の可視化、説明をしないといけないと言う場面がありました。
誰にでもわかるような、レイヤを下げたマニュアルを作ることは本当に難しく、最近になっても修正・加筆を続けています。
あと自分の説明力のなさにうんざりしています。喉が枯れるくらいの分量じゃなくて、もっとスマートに喋れるようになりたい。
■人生で初めて仕事の後輩ができる
8月から弊社の新卒が弊PJに配属になり、「後輩」という存在ができました。
エンジニアとしてのスタート地点が新卒の時の自分と同じような感じなので、親近感を持って教えることができています。
なんとか最近までなんとなくで理解していた技術の言語化を頑張っているのですが、
死ぬほど難しい。。毎日喉を枯らしながらなるべくわかりやすく説明しています。
あと後輩ができるともっと勉強して理解を深めなきゃいけないことが多いと感じます。
フワッとした理解じゃ教えられないこともあるし、教えることが間違ってると辛い・・・😭
-
- -
思いつく限りですがこの半年でやっていたことを書き出してみました。
わりといろいろ頑張っていた気がする。
コロナの時勢なので現場も色々と過渡期でワタワタしてます。
今後は、OracleDB、データ統合ツール、Azureなんかを学ぶ必要がありそうです…。
最近仕事でいっぱいいっぱいになって夜9時くらいに退勤してすぐ寝るという小学生もびっくりの早寝ぶりなのですが、
たまにはこうやってブログ書いたり勉強したりしたいなと思っています。
とりあえず、CKA再受験の為にまたお勉強ですね。
眠気にマケズ、コロナにマケズ、クーラーつけすぎのテレワークから来る夏バテにもマケズ。
皆さんも残暑に負けずお過ごしください。
おしまい
【Docker/Kubernetes実践コンテナ開発入門】 ハンズオンレポート①
お久しぶりです。
年が明けてから残業続きでゆっくりブログを書く暇もなかったのですが、
そろそろ書くことが溜まってきてしまったのでアウトプットしたいと思います。
3日坊主はよくない…
- - -
今日は、12月ごろからCKAの勉強の為に始めた
↓こちらの本のハンズオンを実践中、個人的に詰まった箇所と原因について
書いていきたいと思います。
全然関係ないですがDockerのくじらくんってかわいいですよね。
詰まったところ①
最初に詰まったのは2.5の「Docker Composeでマルチコンテナを実行する」
というハンズオン。
内容的には、Jenkinsのイメージを使ってmaster,slaveのコンテナを
docker-compose.yamlで立て、JenkinsのGUIを使用して
masterからslaveにSSHログインできるように設定するというもの。
こちらは、
「プラグインが正常にインストールされず、slaveへのSSH設定ができない」
と言う問題と、
「なんとかプラグインを導入し、SSH接続の設定はできたものの
接続が行われない」
という二つの問題が起きました。
一つ目の問題は一応一人で解決できましたが、二つ目で心が折れたため
同僚に頼って問題を解決してもらいました。
こちらの問題については、以下の記事にまとめられています。
自分で問題解決できるような何度エラーが起きても折れない強い心と知識が欲しいですね。。
詰まったところ②
次に詰まったところは、3.1の「アプリケーションとコンテナの粒度」という
ハンズオン。
こちらの内容は、cronとjobを同時実行するコンテナを立てるというもの。
具体的には、以下のようなファイルを使用してハンズオンを実践しました。
- ディレクトリ構成
cronjob --- task.sh
|- cron-example
|- Dockerfile
- ジョブ（task.sh）
#!/bin/sh echo "[`date`] Hello!" >> /var/log/cron.log
- cron定義ファイル （cron-example）
* * * * * root sh /usr/local/bin/task.sh
- Dockerfile
FROM ubuntu:16.04 RUN apt update RUN apt install -y cron COPY task.sh /usr/local/bin/ COPY cron-example /etc/cron.d/ RUN chmod 0644 /etc/cron.d/cron-example CMD ["cron","-f"]
手順としては、まずこれらのファイルを作成。
その後、docker buildでイメージ作成、docker run でコンテナ実行という流れです。
以下、イメージ作成、コンテナ実行時のログです。
(コンテナのIDが所々違っていますが、何回も試行錯誤したログから拾っているためです。)
cronjob 17:11:36 hoge $ docker image build -t example/cronjob:latest . Sending build context to Docker daemon 4.096kB Step 1/7 : FROM ubuntu:16.04 ---> c6a43cd4801e Step 2/7 : RUN apt update ---> Running in c8d83cffbdb3 ~~ Step 3/7 : RUN apt install -y cron ---> Running in 0292a56710dc ~~ Step 4/7 : COPY task.sh /usr/local/bin/ ---> ad8839bc9806 Step 5/7 : COPY cron-example /etc/cron.d/ ---> 7223f2859b6c Step 6/7 : RUN chmod 0644 /etc/cron.d/cron-example ---> Running in a5dc6b120564 Removing intermediate container a5dc6b120564 ---> d9c90a65cbc2 Step 7/7 : CMD ["cron","-f"] ---> Running in a57809aa4090 Removing intermediate container a57809aa4090 ---> 9d17d7e6de4a Successfully built 9d17d7e6de4a Successfully tagged example/cronjob:latest cronjob 17:15:20 hoge $ docker container run -d --rm --name cronjob example/cronjob:latest ceea3d51fbe7062c268a37ffb8cface9dac045ba7c0d2ea76e6ef6ccad78ec84 cronjob 17:17:39 hoge $ cronjob 17:17:39 hoge $ cronjob 17:17:39 hoge $ docker container exec -it cronjob cat /var/log/cron.log cronjob 17:18:24 hoge $ docker container exec -it cronjob cat /var/log/cron.log cat: /var/log/cron.log: No such file or directory cronjob 17:19:10 hoge $ docker container exec -it cronjob cat /var/log/cron.log cat: /var/log/cron.log: No such file or directory cronjob 17:19:43 hoge $
おろ…？？
1分経っても2分経ってもログが出されない。
cronjob 15:13:23 hoge $ docker container exec -it cronjob bash root@ab35381b94e8:/# ls -l /var/log total 236 -rw-r--r-- 1 root root 3090 Dec 12 01:51 alternatives.log drwxr-xr-x 1 root root 4096 Jan 25 06:08 apt -rw-r--r-- 1 root root 42621 Dec 12 01:51 bootstrap.log -rw------- 1 root utmp 0 Dec 12 01:51 btmp -rw-r----- 1 root adm 31 Dec 12 01:51 dmesg -rw-r--r-- 1 root root 141863 Jan 25 06:08 dpkg.log -rw-r--r-- 1 root root 3360 Dec 12 01:51 faillog drwxr-xr-x 2 root root 4096 Dec 12 01:51 fsck -rw-rw-r-- 1 root utmp 30660 Dec 12 01:51 lastlog -rw-rw-r-- 1 root utmp 0 Dec 12 01:51 wtmp
/var/logの中身をみてみたりしたけど、やっぱりない。
実行ファイルの中身がおかしかったか？と確認してみるけど、特に問題なさそう。
root@6d4b1785f6fd:/# ls /usr/local/bin task.sh root@6d4b1785f6fd:/# ls /etc/cron.d cron-example root@6d4b1785f6fd:/# ls -l /etc/cron.d total 4 -rw-r--r-- 1 root root 42 Jan 7 12:36 cron-example root@6d4b1785f6fd:/# ps -ax PID TTY STAT TIME COMMAND 1 ? Ss 0:00 cron -f 17 pts/0 Ss 0:00 /bin/bash 27 ? S 0:00 CRON -f 28 ? Ss 0:00 /bin/sh -c test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) 29 ? S 0:00 run-parts --report /etc/cron.daily 30 ? S 0:00 /bin/sh /etc/cron.daily/apt-compat 37 ? S 0:00 sleep 211 43 pts/0 R+ 0:00 ps -ax root@6d4b1785f6fd:/# ls /tmp
他にもファイルがちゃんと配置されてるか、cronが動いてるかを確認してみたけど問題なさそう。
しかし、crontab -lでスケジュール設定されているかを確認してみると…
root@6d4b1785f6fd:/# crontab -l no crontab for root
スケジューリングされてない…？
root@6d4b1785f6fd:/# /etc/init init/ init.d/ root@6d4b1785f6fd:/# /etc/init init/ init.d/ root@6d4b1785f6fd:/# /etc/init.d/c checkfs.sh checkroot-bootclean.sh checkroot.sh cron root@6d4b1785f6fd:/# /etc/init.d/c checkfs.sh checkroot-bootclean.sh checkroot.sh cron root@6d4b1785f6fd:/# /etc/init.d/cron status * cron is running root@6d4b1785f6fd:/# /etc/init.d/cron restart * Restarting periodic command scheduler cron * Stopping periodic command scheduler cron [ OK ] * Starting periodic command scheduler cron
念のためcronを再起動してみるけど効果なし。
やっぱり定義ファイルに問題があるのか…？ということで、
cron定義ファイルの書き方をちゃんと調べて書き直してみました。
（最初から調べて書くべきでした）
イメージを作り直し、もう一回実行してみると…
cronjob 16:19:33 hoge $ docker container run -d --rm --name cronjob example/cronjob:latest c4a33f2a2c92b6f21a99333f354d0cb223d183737582cf03a405b42d8058479b cronjob 16:19:43 hoge $ docker container exec -it cronjob cat /var/log/cron.log cat: /var/log/cron.log: No such file or directory cronjob 16:19:57 hoge $ docker container exec -it cronjob cat /var/log/cron.log [Sat Jan 25 07:20:01 UTC 2020] Hello!
おお！ログが表示された！
どうやら、crontabの書き方が間違っていたようです。
今回のキモはこちらのサイトの以下の部分です。
「第 6」フィールド (行の残りの部分) には実行されるコマンドを指定する。
その行のコマンド部 (改行文字または % 文字まで) が /bin/sh
(またはその crontab ファイルの SHELL 環境変数で指定されたシェル) によって実行される。
最初はてっきりタブとスペースの置き方をミスっていたのかと思いましたが、
crontabを書くときはどこまでが実行コマンドかを判断させるために改行文字か％をコマンドの後ろに置く必要が
あったみたいです。
以前職場で、あるサーバのバックアップをとるためにバックアップシェルをcronで日次実行しようとしたとき、
何故か次の日実行されておらず、原因が分からずじまいでしたが
やっとわかりました。よかったよかった。
まとめとおまけ
一旦今日はここまでです。
12月上旬から始めてハンズオンにめちゃくちゃ時間がかかっている理由は、
こちらが原因です。
ハンズオン、理解が進んで楽しいんだけど、ファイル作成と参考書を読むことを交互に進めるのが非常に苦痛。。
— Mamekonb (@mamekonb) 2020年1月18日
なので一気にファイルを作成して後で一気に実行することにした
こないだやっとハンズオンで使用するすべて（？）の資材を作成し終わったので、
今日からやっとハンズオンを再開し始めた次第です。
資材を作るのがめんどくさい！という方は以下のgithubリポジトリを公開しておりますので
よろしければどうぞ。
くじらくんに癒やされながら残りのハンズオンも頑張っていきたいと思います。
おしまい
Plant UMLを使用してディレクトリ構成図を書いた話
こんにちは。
現在母方の実家にきていますが、茨城は寒いですね。
学生時代も茨城に住んでいましたが、寒暖差が激しすぎて
四季を楽しむ余裕が無かった気がします。
さて今日は今年の仕事納めでPlant UMLなるものを知り、多少書き方を学んだので
その話をしようと思います。
背景
仕事最終日、特に急ぎの仕事もないのでずっと作ろうと思っていた業務マニュアルを
作成することにしました。
業務マニュアルを作成する過程で、ディレクトリ構成図を描く必要がありました。
めんどくさいなと思いながらパワポでポチポチしていたら、先輩に
「Plant UML使ってみれば」と提案され、
なんじゃそらと思っていると次のようなことを言われました。
・パワポでぽちぽちお絵かきってめんどくさいよね
・要素増えたりしたら位置移動が必要
・そもそも細かい図を作るのにPowerPointは向いてない
・パワポは絵心がない人間が作ると視認性が低くなる
・そんなときは、、ﾀﾘﾗﾗｯﾀﾗ〜〜〜〜〜〜
Plant UML〜〜〜〜〜〜〜〜〜〜！（
Plant UMLとは
PlantUMLはオープンソースのUMLダイアグラム作成用のテキストベースの言語である。PlantUMLの言語はドメイン固有言語の一例である[4]。ダイアグラムの表示にはGraphvizを使用している。
だそうです。
細かい図（ダイアグラム）を描画することに特化した言語みたいです。
コードを書くと自動的に図が描画され、配置やらなんやらはよしなにやってくれます。
オプションを使うことで、自分で配置や色をカスタマイズすることもできるようです。
シーケンス図や構成図などなど、エンジニア御用達のあんな図こんな図を
コードを書くだけでサクサク描けるようです。
使い方に関しては、先人が書いてくださっているのでそちらをご参照ください。
Plant UMLというパッケージを入れれば、vscodeで書いてすぐにプレビューできます。
描いたもの
私は今回、Ansibleに関してのディレクトリ構成図を書きました。
コードがこんな感じ。↓
@startuml
skinparam backgroundColor aliceblue
top to bottom direction
title Ansible_role構成図
frame "server#01" {
folder root
folder ansible_role {
folder roles {
folder role_name {
folder defaults {
file main.yaml as a
}
folder files {
file hoge.cfg
}
folder handlers {
file main.yaml as b
}
folder meta {
file main.yaml as c
}
folder tasks {
file main.yaml as d
}
folder templates {
file main.yaml as e
}
folder tests {
file main.yaml as f
}
folder vars {
file main.yaml as g
}
}
}
folder group_vars {
file group_vars.yaml
}
folder host_vars {
file host_vars.yaml
}
file ansible.cfg
file Playbook.yaml
file inventory.01
file inventory.02
}
root -- ansible_role
vars -[hidden]- meta
meta -[hidden] files
files -[hidden] handlers
handlers -[hidden] tests
ansible.cfg -[hidden]- Playbook.yaml
Playbook.yaml -[hidden]- inventory.01
inventory.01 -[hidden]- inventory.02
host_vars -[hidden]- group_vars
}
@enduml
で、実際描けた絵がこんな感じ。↓
ツリー構造を表現したいというよりは、
パッケージ図のようなイメージでAnsible_roleディレクトリの中身を説明するものが作成したかったので
このような描き方になりました。
つまづきポイント
カスタマイズ的な観点で言うと、思い通りにならないことが割とありました。
使い慣れてないってこともありますが、、
以下二点がつまづいたポイントです。
配置がイマイチな時がある
そのままオブジェクトを配置すると、オブジェクトの数が多い時などは
配置がイマイチな時があります。
以下は配置だけ行い、何もしない例です。
コードがこちら。
@startuml
skinparam backgroundColor aliceblue
top to bottom direction
title Ansible_role構成図
frame "server#01" {
folder root
folder ansible_role {
folder roles {
folder role_name {
folder defaults {
file main.yaml as a
}
folder files {
file hoge.cfg
}
folder handlers {
file main.yaml as b
}
folder meta {
file main.yaml as c
}
folder tasks {
file main.yaml as d
}
folder templates {
file main.yaml as e
}
folder tests {
file main.yaml as f
}
folder vars {
file main.yaml as g
}
}
}
folder group_vars {
file group_vars.yaml
}
folder host_vars {
file host_vars.yaml
}
file ansible.cfg
file Playbook.yaml
file inventory.01
file inventory.02
}
root -- ansible_role
}
@enduml
図が非常に横長になっていますね。
これは折り返すなどしてもっと図をコンパクトにしたい。
無駄なスペースにオブジェクトを置いてなるべく全体像を正方形に近づけたい。
これを
こうしたい
「Plant UML 折り返し」「Plant UML 改行」などで調べてみても
特にそれっぽい事例は出てきませんでした。（検索下手）
レイアウトのやり方で調べてみることに。
すると以下のページが見つかりました。
打倒！PlantUMLのなにこれレイアウトのその後 - VELTRA Engineering - Medium
おお…これこれ！これや！私がやりたかったんはこれや！
ページを飛ぶのがめんどくさい人向けに簡単に説明すると、
Plant UMLのレイアウトは相対的に行うものなので、オブジェクトを独立させた状態で動かす事は難しいのです。
なので、配置させたい位置の近くにあるオブジェクトにリンクを使って動かしたいオブジェクトを連結させ、
リンクを隠してしまえば一見独立した状態でそこに位置しているように見えると言う訳です。
文字で説明するのが難しいですね。上記の説明だとわかりづらいと思うので、図で説明すると
こんな感じです。
早速実行してみると…
~ root -- ansible_role #以下のコードを追加 vers -[hidden]- meta } ~
こうなりました！あとは、metaオブジェクトの横に連結させて同じようにリンクを隠せば…
~ root -- ansible_role vers -[hidden]- meta #以下のコードを追加 meta -[hidden] files files -[hidden] handlers handlers -[hidden] tests } ~
完成図です。
まだ図としては横長なので、group_versやhost_versなど他のオブジェクトも
縦にリンクを貼って図をコンパクトにします。
すると、上のような図になります。だいぶ、縦横比のバランスが良くなりました。
エイリアスとオプションは併用できない
マニュアルとして図を作成しているので、ファイル名の他に簡単な説明文なんかも
ファイルに書きたいと思いました。早速調べてみると、公式ページには
オプションをつけることでオブジェクトの中にテキストを入れることができるという
記述がありました。
説明文が長くなる場合は、オプションでテキストを [] の中に書くこともできます。
図の中でいう「main.yaml」の中身の説明文をファイルオブジェクトの中に書きたい
と思ったので、早速実行。
~
folder tasks {
file main.yaml as d [
メインで行うタスクを記述する
]
}
~こうしてみると、
syntax Errorになってしまいます。あれれ？と思いながらとりあえず
公式ページに書いてあるようにしてみると、、
~
folder tasks {
file main.yaml [
メインで行うタスクを記述
]
}
~
今度はちゃんとオプション内の説明文が表示された。
でも、オプションをつけるとファイル名は表示されなくなるらしい。
異なるディレクトリに配置されるmain.yamlという名称のファイルが複数存在するので、
名称をmain.yamlとしてエイリアスを適当にa,b..で割り振っていましたが、
エイリアスとオプションは併用できないようです。
ディレクトリ名は固有なので、じゃあディレクトリの説明文に
つけられないの？と試してみましたが
~
folder tasks {
メインで行うタスクを記述
file main.yaml
}
~~
folder tasks { [
メインで行うタスクを記述
]
file main.yaml
}
~
どちらも、syntaxErrorになってしまいました。
なるほどこういう書き方はできないのか、、
オプションを利用したいなら、識別子を固有にするしかないみたいですね。
もしくは、ノートオブジェクトをつけることもできますが、場所的にかさばりそうなので
今回は識別子を固有にして対応したいと思います。
ノートオブジェクトはこんなの↓
~
folder tasks {
file main.yaml
}
note bottom: コメント
~
以下、オプションを使用する際に注意する点まとめです。
・エイリアスとは併用できない。
・ファイル名を表示したい場合は、オプションの1行目にファイル名を記述する必要がある。
・入れ子構造にしているものに直接オプションをつける事はできない。
謎のデイリータスクを半自動化した話
こんにちは。
早いものでもう年末ですね。
昨日、人生で初めてスケートを体験して見事に転けて右肘を強打しました。
今日は、先週あたりから発生したデイリータスクを半自動化した話をしようと思います。
前提
タスクが発生した経緯：
先々週末からopenshiftノード内にあるdockerイメージがなんらかの理由で
消えてしまうという問題が発生している
タスクの内容：
恒久対処までの間日次でイメージがなくなっていないか確認する
具体的な作業内容としては、「必要なイメージ一覧」があり、
それとノードが保有しているイメージ一覧を出力→比較して、
無いものがあったらリポジトリに入り、イメージを再取得するという流れです。
この「比較」という作業が非常にめんどくさい。
なぜかというとただdocker images を叩くだけだとイメージ名が全く同じものや、
似た名前のイメージが大量に出てくるから。
しかも、確認するノードは複数、、、
タスクをやり始めて1日目は確認することを教わりつつやったのでそんなに作業感を感じなかったんですが、
恒久対処の日程が今のところ決まっていないと知った2日目から
既に死ぬほど虚無を感じる作業になってしまいました。
「比較して差分を取得」というタスク自体は非常に単純なものなので、プログラミングですぐに実装できそう。
サクッと自動化してみるか！と思い立ち、やってみることにしました。
やったこと
まず扱うファイルの中身と、処理の流れと、欲しい出力をイメージしました。
さらっと書いた流れが↓こんな感じ。
メモが汚すぎるので一応説明すると、
・checklist → 存在していて欲しいイメージのリスト
・imagelist → 取得したイメージのリスト
流れとしては、
①「イメージ名のみの一覧ファイルを整形して出力」
↓
②「差分を比較して、checklistにあるけどimagelistに存在しないイメージ名があれば出力」
の二段階。
①はコマンドでなんやかんやして出力しました。
sudo docker images | cut -d' ' -f1 | tail -n +2 | sort | uniq > imagelist.txt
処理的には、
・docker imagesで一覧を取得
・一列目（イメージ名）だけを指定して出力
・アルファベット順にソート
・重複しているイメージを除外
・imagelist.txtと言う名前で出力
ということをしております。
コマンドは先人の知恵をお借りしました。
②はpythonで実装。普段使っているrubyで書きたかったけど、現場の環境にインストールされていなかったので調べながら、、
#checkimage.py checklist = open("checklist.txt","r") imagelist = open("imagelist.txt", "r") checklists = [] imagelists = [] for line1 in checklist: checklists.append(line1) for line2 in imagelist: imagelists.append(line2) for check in checklists: if check not in imagelists: print(check.rstrip('\n')) checklist.close() imagelist.close()
処理内容：
・ファイルを開く
・1行ずつリストに要素として入れる
・checklistの要素一つ一つに対して、imagelistに存在するかどうかチェックする
→存在しないイメージがあった場合、イメージ名を改行文字を取り除いて出力
・ファイルを閉じる
わざわざ配列に入れる必要はないのかもしれませんが、そこは知識と時間不足でした、、
もしもっとスマートな書き方を知っている方は教えてください🙇♀️
まとめ
正直、最初のコマンドでファイルを出力するだけでもだいぶ無駄なイメージが削ぎ落とされて出てくるので楽になるんですが、
winmerge開いて比較して〜ってところもめんどくさすぎて毎日やるとなると大変だったので
コマンド二つ叩くだけで日次タスクが終了するとなっただけでも大分工数が削減できたんじゃないかなと思います。
ホントはシェルスクリプトにpythonを埋め込んで、一つ実行するだけで不足イメージ名が取得できるところまで
できれば良かったんですがその辺は業務中に調べきれず実装できてません。少し調べればできそうですけどね。。
現時点ではイメージがなくなる問題は再発していませんが、
毎日ガンガンなくなるようであればイメージを取得するところも自動化しようかなと思っています。
おしまい
