Fugu Log

技術とたまに日常生活のことについて書いていきます

ネムリラのバッテリーが壊れたので交換してもらった話

はじめに

こんにちは。

 

数ヶ月前に第一子が生まれ、日々目まぐるしく過ごしています。

初期育児において何が大事かって、「いかに寝てくれるか」がめちゃくちゃ重要です。

 

生まれてすぐの赤ちゃんは聴覚はあるものの、目はほとんど見えておらず、泣いてしまった時に遊びやあやしなどで気が紛れることは正直あまりありません。

 

大体、空腹か眠たいのに眠れないかオムツ変えて欲しいか、はたまた抱っこなどの触れ合いをしたいか。

 

空腹やおむつは対応すればすぐ済む話ですが、眠りの環境やあやし方は一筋縄ではいかず、我が家では試行錯誤の末、電動バウンサーの「ネムリラ」にかなり助けられていました。

抱っこじゃないと寝ない時期でも、ネムリラに乗せて揺らしてあげるとスッと寝てくれることが多く、今では我が家の育児に欠かせない存在になっています。

 

そんな頼りにしていたネムリラなのですが、先日ちょっとしたトラブルに見舞われました。今回はその顛末と、メーカー対応で助かった話を書いてみようと思います。

 

ある日突然、ネムリラが動かなくなった

我が家では育児用品として、コンビの「ネムリラ」(電動タイプ)を使っています。

 

www.combi.co.jp

 

いつも通り使おうと思ってバッテリーを繋いだのですが、まったく動かない…。

「あれ?」となりつつも、こういう時こそ職業病。まずは落ち着いて、何が原因なのかを切り分けることにしました。

 

確認した内容は以下の通りです。

 

  • バッテリーを付属のタイプCケーブルでネムリラ本体に繋いでも、動かない
  • タイプCケーブルをACアダプター用のもの(タイプC to C)に変更し、バッテリーとネムリラを繋いでも、やはり動かない
  • ACアダプターをネムリラへ直接繋ぐと、問題なく動作する
  • バッテリー自体への充電もできない。ケーブルを変えても状況は変わらず

 

ここまで確認した結果、

  • ネムリラ本体は正常(ACアダプター直結では動く)
  • ケーブルが原因ではない(複数のケーブルで試しても同じ症状)
  • バッテリー側で「充電」も「給電」もできていない

という切り分けができ、バッテリーのタイプCポートが物理的に故障している可能性が高いという結論にたどり着きました。

 

(ちなみにバッテリーにはタイプAポートもついていますが、こちらは利用できないことが説明書に記載されています。)

 

どこに問い合わせればいいのか分からなかった

最初にやったのは、コンビのネムリラ専用サイトを確認することでした。

しかし、故障しているのはネムリラ本体ではなくバッテリー。「ネムリラのサイトに問い合わせるのは何か違う気がする…」と、モヤモヤしながらページを眺めていました。

 

そこでふと思い出したのが、開封時に説明書を読んだこと。

「そういえばバッテリー単体の説明書もあったはず」と探してみたところ、捨てずに保管してあり、無事にバッテリーメーカーの連絡先を確認できました。

 

購入日と故障日を確認 → 保証期間内と判明

そもそも最近購入したものなので余裕で保証期間内ということはわかっていたのですが、念のため日付を確認したところ

  • ネムリラ(バッテリー含む)が届いたのは 5/30
  • 故障が発覚したのは 7/1

ということで、保証期間内ということより、1ヶ月ちょいで壊れたんか・・・結構高いのに・・・という気持ちになりました。

 

メーカー対応がとにかく早かった

バッテリーメーカーへ電話で事情を説明し、その後メールで購入日や症状に加え、上記の切り分け内容もそのまま送付しました。すると、そこからの対応が驚くほどスピーディーでした。

日付 出来事
7/1 電話で問い合わせ・状況説明、メールで詳細情報を送付
7/2 交換品の発送連絡
7/3 交換品到着。届いた箱に故障品をそのまま入れて返送し、完了

問い合わせから交換完了まで、わずか3日でした。

対応してくださった担当者の方は、いわゆる「ホスピタリティ高め」の丁寧すぎる対応、というタイプではなかったのですが、話が早くて的確。必要なことを淡々と、でもしっかり進めてくれる印象で、育児中で時間に余裕がない身としてはむしろありがたかったです。

正直、規模がそこまで大きくなさそうな会社だったので少し不安もありましたが、対応の速さと確実さを見て、その心配は杞憂だったなと感じました。

 

交換は完全無償

修理費用や送料など、こちらの負担は一切なく、無償で新品と交換していただけました。

 

この経験から伝えたいこと

同じように育児用品のバッテリートラブルに悩む方に向けて、今回学んだポイントをまとめておきます。

 説明書・保証書は捨てない

高い買い物は説明書や保証書は取っておくタイプなのですが、バッテリーの取説は本体とは別で小さいものだったのでもしかして捨ててしまったか・・・?と一瞬冷や汗をかいていました。今回は取っておいたおかげで問い合わせ先がすぐに分かりました。(私はバッテリーの取説で問い合わせ先を確認しましたが、一応問い合わせ先はネムリラの取説の端っこにも書いてあることを後から気づきました。ただし、バッテリーの保証書はバッテリーの取説の方にほうにしか付いていません)

同梱のものでも今回のように取説や保証書が別である商品もあるので、注意が必要ですね。

 

贈り物の場合は、購入時の情報を確保しておく

我が家の場合、ネムリラは義実家からの贈り物でした。保証対応には購入日を証明できるものが必要だったため、義実家に購入時のメールなどが残っていないか確認したところ、メールはすでに残っていませんでした。

ただ、幸い領収書のデータは残っており、これでなんとか保証対応をお願いすることができました。

 

贈り物としてお高めなベビー用品をもらう場合は、保証時に困らないように**「購入日が分かるもの(領収書・メールなど)だけでも一緒にいただいておく」**ようお願いしておくと、いざという時に安心です。

 

まとめ

  • ネムリラのバッテリー不具合はバッテリーメーカーへ
  • 説明書・保証書は本体・バッテリーともに保管しておく
  • 贈り物の場合は購入日が分かる資料を確保しておく
  • 今回のメーカー対応は「無償交換・3日でスピード解決」で大満足

 

育児グッズは毎日使うものだからこそ、いざという時のためにこうした情報を残しておくのは大事だなと改めて感じた出来事でした。同じような状況で困っている方の参考になれば嬉しいです。

 

おしまい

 

 

駆け出し個人開発者がMicrosoft Partner Centerでアドオンありのアプリ申請をしてみた話

目次

はじめに

こんにちは。お久しぶりです。

最近はAIの発達が目覚ましいですね。「アプリ開発全くの未経験の私が、AI使ってどのくらいのものが作れるんだ?」と興味本位で、育児の合間にちまちま作っていたら、ノってきてしまって結構ちゃんとしたものが作れてしまいました。AIってすごいですね。

作ったのは「Calcjot(カルクジョット)」という、計算式に名前をつけて保存できる電卓アプリです。

作り始めた当初は「ちょっと作ってみるか〜」くらいのテンションだったのですが、気づけば夫に促され、Microsoft Storeへの申請というフェーズまで来てしまいました。そして、機能開発は楽しかったのですが、申請作業がまあまあ沼でした・・・・

今回は、個人開発者としてMicrosoft Partner Centerでアプリを申請してみた記録を書いていこうと思います。特に、有料版(アプリ内課金アドオン)の提出に向けた税務・支払い設定まわりで思ったより手こずったので、その辺を中心に残しておきます。

これから個人でMicrosoft Storeに申請しようとしている方の参考になれば幸いです。

 

背景

まず簡単にアプリの説明と、申請周りの前提を整理しておきます。

もともと家計簿管理でヘビーユーズしていた計算メモアプリがあったのですが、使っているうちに「あれがあったらいいのに」「これがこうならいいのに」という要望がいろいろ出てきていました。
レビューに書こうかな?と思ってAppStoreを開いてみると、そのアプリの開発は4年前で止まってしまっていました。それなら自分で作ってみよう、と思ったのがCalcjot開発のきっかけです。

Calcjotは、計算式に名前をつけて保存し、他の式から参照できる計算メモアプリです。複数シート管理や、合計・平均・分散などの集計機能もついています。

開発者アカウントは個人事業主として登録しています。アプリストア上の発行者名にはフリーランスとしての屋号である「Sunny Byte」を使っています。

初回リリースなので、収益モデルはシンプルな2段構成にしました。

  • 無料版:計算シート3枚まで、テーマは白のみ
  • 有料版:シート無制限+全7色のテーマ解放(買い切りのアプリ内課金アドオン)

つまり、Microsoft Storeには「Calcjot本体(無料)」と「FullVersionUnlock(有料アドオン)」という2つのものを申請する必要があります。

本体の審査には数日〜かかると聞いていたので、まず本体だけ先に申請を出し、「アドオンの方はその間に準備しておこう」くらいの気持ちでいました。

 

フライング申請失敗

本体を申請した翌日、「じゃあアドオンも出しておくか」と軽い気持ちでPartner Centerを開きました。

アドオンページを見ると、申請1のステータスは「送信されていません」。よし、じゃあ出すか、と概要ページを一通り確認していくと……

アドオンの親アプリが公開されるまで、このアドオンを提出することはできません。

 

出ました、赤いエラー文。

 

どうやら、アドオンと親アプリは同時並行で申請を進められるわけではなく、親アプリが実際にストアで「公開」された後でないと、アドオンは提出すらできないという仕様のようです。審査中とか申請済みではダメで、あくまで「公開済み」がボーダーラインという厳しさ。

しかもよく見ると、もう一つエラーが出ていました。

支払いを請求する前に、税務情報および支払い情報を更新する必要があります。

確かに、有料版公開するのはいいけどお金ってどうやって入ってくるんだろ?と頭の片隅で思っていました。

なるほど、これがその設定というわけですね。

 

本体の公開を待つのはどうしようもないとして、税務・支払い情報の方は今すぐ着手できます。

というわけで、早速Partner Centerの「支払いと税」設定をしていくことにしました。

 

税務プロファイル登録

アカウントの設定から支払いと税プロファイルの設定画面を開くと、当然ながら何も登録していない状態でした。面倒そうだけどまずは税プロファイルから手をつけることに。

事業上の名称(DBA)って何?

最初に出てきたのが「事業上の名称(DBA)」という欄。DBAは「Doing Business As」の略で、法的な登録名とは別に対外的に使っている屋号を書く欄でした。

 

私の場合、Partner Centerに登録している法的名義は本名で、発行元ID(対外的な屋号)は「Sunny Byte」としていました。この2つが違うパターンだったので、DBA欄には屋号を記入しました。

税居住国を選ぶだけなのに詰まる

続いて税居住国は日本を選択。その次に出てきたのが「税IDの種類」というプルダウンで、選択肢は「VAT番号」か「VAT登録されていません」の二択。

 

VATって何?と一瞬固まりましたが、調べてみると要はEU圏などで使われる付加価値税の登録番号のことで、日本の消費税とは別物。日本の個人事業主が持つことは基本的にないので、迷わず「VAT登録されていません」を選択すればOKでした。

W-8BENという書類を初めて知る

税フォームのセクションに進むと、「米国」向けのフォーム提出を求められました。

え、なんで米国?と思ったのですが、Microsoftが米国企業である以上、日本居住者への支払いに対しても、米国側の源泉徴収税をどう扱うかを申告する必要があるとのこと。日本居住者の場合、日米租税条約に基づいて源泉徴収を軽減してもらうために「W-8BEN」というフォームを提出します。これを出さないと、報酬の一部が高い税率でごっそり米国側に持っていかれてしまうらしい。

「税フォームの起動」を押すと、S&Pグローバル マーケット インテリジェンス社という外部サービスのフォームに飛ばされ、そこで実際の入力を行う流れでした。

 

日本の開発者の方は一番下にチェックを入れないよう要注意

途中、「実質的に関連する所得」という項目にチェックを入れるかどうかの選択肢があったのですが、これは米国内に事業拠点を持ち、米国へ納税申告をしている場合(W-8ECIというさらに別のフォームが必要になるケース)の話で、普通に日本で活動している個人開発者には関係ないやつでした。

なんかチェックを入れないと進まないやつかと思い、危うくノリでチェックしそうになりましたが、ちゃんと条件を読んで事なきを得ました。

意外とあっさり終わったW-8BEN

氏名、住所、市民権のある国、税務上の居住地……と一通り入力し、最後に「偽証罪の適用があり得ることを認識した上で」云々という宣誓文にチェックを入れ、電子署名としてローマ字氏名を入力して完了。

 

拍子抜けするくらいスムーズに終わり、税プロファイルのステータスはすぐに「完了」に変わりました(検証に最大48時間かかると案内されていたので身構えていたのですが、体感かなり早かったです。申請してから2-3時間で承認されていました)。

税務フォームはこれで一段落。しかし本当に沼だったのはこの後の「支払いプロファイル」設定でした。

 

支払いプロファイル登録

税プロファイルが終わったので、続いて支払いプロファイル(銀行口座情報)の登録に進みます。……と思ったら、まずどこから登録すればいいのか分からず彷徨うところからのスタートでした。

追加ボタンがどこにもない

「Payout and tax profiles」の「支払いプロファイル」タブを開くと、「現在、支払いプロファイルがありません」の文字だけがぽつん。追加ボタンらしきものはどこにも見当たりません。

 

何もない

結局、正解は別の画面にありました。「Payout and tax profile assignment」(支払いと税プロファイルの割り当て)の方から対象プログラム(Microsoft Store)を選び、「Edit」を押して開いたパネルの中の「支払いプロファイル」欄でどちらかのビジネスエンティティを選んで、上部の「Edit」を押すことで初めて銀行プロファイルを新規作成するための導線が現れる、という仕組みでした。分かりにくい……。

プロファイル名に日本語を入れてエラー

銀行プロファイル作成画面が開けたので、プロファイル名を入力して次へ進もうとしたところ、赤枠でエラー。

どうやらこの欄は英数字のみ対応で、日本語(全角文字)が入っていると弾かれる仕様でした。「SunnyByte Bank Account」と英語表記に変えたら、あっさり通過。

全銀コードと支店コードの入力のクセ

 

続いて銀行口座の詳細入力。「JPRN全銀コード:4桁の銀行コードと3桁の支店コード」という欄があり、これは日本の銀行に割り振られている統一金融機関コード(4桁)と支店コード(3桁)を、続けて7桁の数字として入力するものでした。

(このあたりのコードは何かの申請の際に使うことはありましたが、繋げて入力するのは初めてでした。私が知らないだけでスタンダードな入力方法なんでしょうか)

入力すると自動で銀行名・支店名(英語表記)が表示され、ちゃんと認識してくれているのが分かりました。

「貯蓄」はあるのに「普通」がない



口座の種類を選ぶプルダウンには「確認中」と「貯蓄」の2択。「確認中」って何、審査状態のこと?と困惑しましたが、これはおそらく英語の「Checking(日常的に出し入れする口座)」が機械翻訳でそのまま「確認中」になってしまっているだけでした。日本でいう普通預金にあたるのはこちらなので、「確認中」を選択。

Beneficiary、完了までが長い

銀行口座情報の後は、受益者(口座名義人)情報の入力。氏名や住所を入れて、ようやく「Bank Account」「Beneficiary」ともに「Complete」のチェックマークがつきました。

これでようやく銀行プロファイルの作成は完了……のはずだったのですが、まだ終わりではありませんでした。

 

送信ボタンが押せない謎

銀行プロファイルも無事に作成でき、「Payout and tax profile assignment」の画面に戻ると、Microsoft Corporation(Sell)の行に、作成したばかりの「SunnyByte Bank Account」がちゃんと紐づいていました。

これでよし、と思って画面下の「送信」ボタンを押そうとしたら……押せない。グレーアウトしたまま。

 

 

何度確認しても不足項目が見当たらない

  • ラジオボタンはちゃんとMicrosoft Corporation(Sell)の行を選択している
  • 税プロファイルも「Japan(Seller: xxxxxxxx)」が選ばれている
  • 支払いプロファイルも「SunnyByte Bank Account」が入っている
  • テーブルを右にスクロールしても、それ以上隠れている必須項目は見当たらない

一見すべて揃っているように見えるのに、送信ボタンだけが頑なに押せない状態。ページの再読み込みも試しましたが変化なし。しばらく画面とにらめっこすることになりました。

ダメ元でAdsRevenueの行にも同じ設定を入れてみる

画面には、Microsoft Corporation(Sell)の行のほかに、もう一行「Microsoft Online Inc.(AdsRevenue)」という行があり、こちらは支払い方法が「Unknown」「Not selected」のまま放置されていました。

Calcjotには広告収益はまだ導入していないので関係ないだろうと思っていたのですが、ダメ元でこちらの行にも同じ支払い方法(Electronic Bank Transfer)と同じ銀行プロファイル(SunnyByte Bank Account)を設定してみたところ——送信ボタンが有効化されました。

やっと送信できる

どうやら、Microsoft Store全体の支払い設定を有効化するには、そのプログラムで発生しうる収益種別(Sell・AdsRevenue)両方に対して支払い方法を割り当てておく必要があったようです。ラジオボタンでの選択はあくまで「今どの行を見ているか」の表示であって、送信自体は画面全体の設定に対して行われる、という理解に落ち着きました。

無事「送信」を押すことができ、税プロファイル・支払いプロファイルともに「完了」、確認の状態だけ「Microsoftの検証保留中」という表示に変わりました。

 

 

まとめ

というわけで、Microsoft Storeへのアプリ申請そのものより、アドオン申請の方が意外と鬼門でした。振り返ってみると、詰まった箇所はだいたいこの4つでした。

  • アドオンは、親アプリが公開されるまで提出できない(審査中・申請済みではダメ)
  • 支払いプロファイルの新規作成ボタンは、思ってもみない場所(プロファイル割り当て画面の中)にある
  • 銀行プロファイル作成時は、プロファイル名を英数字にする、全銀コードを7桁続けて入力する、といった細かいルールにハマりやすい
  • 送信ボタンが押せないときは、収益種別(Sell / AdsRevenue)両方に支払い設定を入れる必要があるかもしれない

現状、Calcjot本体は審査中、税プロファイル・支払いプロファイルはどちらも完了、アドオンの提出だけが親アプリの公開待ちという状態です。

内容そのものの複雑さもさることながら、正直UIが分かりづらすぎるというのも大きかったです。追加ボタンがどこにあるか自体を探すところから始まったり、必須項目が全部揃っているように見えるのに送信ボタンだけ押せなかったり……。それに加えて、ページ遷移がとにかくもっさりしていて、一つ操作するたびに待たされるので、「あれ、今の操作反映されてるのか?」と不安になりながら進める場面が何度もありました。反映確認にも時間がかかるので、とにかくストレスでした。

地味にこの2つが一番作業の足を引っ張った気がします。

 

公式ドキュメントも一応存在するのですが、手順の存在は書いてあっても、実際にどんな画面が出てどこで詰まるかまでは踏み込んでいない印象でした。今回の記事がその隙間を少しでも埋められたらと思います。

これから個人でMicrosoft Storeに、特にアドオンありで申請しようとしている方の、なにか参考になれば幸いです。

Calcjotが無事公開されたら、またこのブログで報告したいと思います。

 

おしまい

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年の記事が見つかりました。

you-it-blog.hatenablog.com

上記の記事の方は大阪で受験したとのことですが、私は埼玉で受験しました。

以下のLFの記事では受験予約で指定したリージョンでリモデ環境が構築されるようにネットワーク遅延の問題が修正されたと記載されていますが、本当に修正されたのか?と思うくらいの遅延でした。

 

training.linuxfoundation.org

「受験者の環境を揃えることで公平性を保つ」という理由で新しいプラットフォームにしたはずなのに、地域によって受験環境に差分が出るのはどうなんでしょうか。

受験する地域やネットワークの速度によってここまで受験環境に差分が出ることが懸念されるなら、受験前のPCでの環境チェックでそこまで確認できるようにするか、そもそも日本での受験を受け入れること自体やめる方が誠意のある対応なのではと思いました。(これらのクレームはアンケートに記載しました)

2回目の受験

1回目で散々な目に合ったのでやる気をなくしてしまい、まだバウチャー期限まで2週間ありましたが1週間後に再受験することにしました。

2回目は前回の対策も踏まえて以下の環境で受験することにしました。

  • 自宅で受験
    • 田舎なので近くに貸会議室が少なかったことや、貸会議室のネットワーク速度を事前に知ることは難しいと思い、自宅で受験することにしました。
    • 自宅では事前にネットワーク速度を確認したところ、以下のような結果でした。

  • 受験時間を早朝(6:00)に設定
    • ネットワーク遅延を少しでも減らすために混雑しないような時間にしました。

これらの対策をしても遅延が改善されない場合、私も上記の記事の方と同様にクレームを入れて返金してもらおうと思っていました。

 

2回目の受験前のチェック(身分証明、試験環境チェック)は1回目の反省が活きたのか、比較的スムーズに受験開始することが出来ました。

自宅で受験する場合、デスク回りを極力何もない状態にしておくことをお勧めします。

私はディスプレイ、外付けキーボード、マウス、PCだけの状態にしましたが、

普段電源タップをくっつけているマジックテープやコードクリップに異様に食いつかれました。(結局マジックテープは剥がせといわれました。。粘着式だったので剥がすのが大変でした)

 

そしてとうとう2回目の試験が開始され、肝心の遅延はというと・・・

1回目よりは断然マシ、という感じでした。

やはり時間経過と共にレスポンスは遅くなっていくと感じたのですが、Wi-fi速度が1回目の2倍くらい早いため1回目ほどひどい遅延は感じませんでした。最後らへんになってレスポンスに2~3秒かかるくらい。

また、問題の内容について大半は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」という講義です。

www.udemy.com

こちらは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の基礎から勉強する為にいわゆるくじら本と言われている参考書のハンズオン

www.amazon.co.jp

  • Mirantis KC-100(会社で受けさせてもらった)

内容的にはdocker,k8sの基本て言う感じです。

  • 会社のdocker初級アカデミー
  • udemyのCKA対策講座

www.udemy.com


本格的な勉強はudemyの講座を中心に勉強をすすめました。
こちらはplactice、模擬試験が優秀なので、とてもおすすめです。本当の試験に出てくる問題もかなりあります。
普通に買うと結構高いですがちょくちょくやっているセールで買うと1300円程度で購入できるので是非狙ってみてください!!

ただし、講座の動画は完全英語なので英語に馴染みがない方はみるのに骨がいるかもです・・・

1回目受験/結果/反省

■試験資格

去年のlinux foundationのサイバーマンデーで購入した無料バウチャーを使って受験しました。
金額はlinux foundationのトレーニング込みで、188.97$でした。(日本円で2万ちょい)
普通にこのコース(試験+トレーニング)を買うと499$みたいです。

認定Kubernetes管理者-Linux Foundation-トレーニング

■試験日

本当は6月中旬に試験予約をしていましたが、linux foundationのメンテナンスに試験日が被ってしまい
ずれ込んで2020/06/27に受験しました。
問答無用で試験のキャンセルメールがきていました…先に言ってほしい…

■試験場所

場所は自社の会議室を借りました。
一度場所を借りたのに上記の通りlinux foundationのメンテナンスに被ってしまい、キャンセル料を徴収されてしまいました。。
完全個室の貸し会議室はそこそこ高いのに…先に言ってほしい…

■試験準備

試験に必要なもの、環境に関してはlinux foundationのダッシュボードからCertification > Resumeをクリックで
確認、準備ができます。

試験時に英語の名前と顔写真が確認できる証明書が必要なのでパスポート取らなきゃいけないか・・・?と
ヤキモキしていましたが、クレジットカードとマイナンバーカードでいけると言う話を聞いたので
特にこの辺は用意せずでした。

■試験当日

試験概要に書いてあるのもあると思いますが、一応気になったポイントを書いていこうと思います。

  • 試験は3時間
  • 透明の入れ物であれば飲み物を飲むことも可能。
  • 公式ドキュメントを1タブ開くことができる
  • 試験15分前にpsiの「My Exams」ページに「take exam」というボタンが出てくる。クリックするとページに飛ぶ。
  • 試験前に画面共有、webカメラ・マイク共有・試験環境確認などの準備がある
  • 英語の試験しか選べなくて心配だったけど結局日本語で受けれた(最初のチャットも依頼すれば日本語でしてくれる)
  • 試験終了10分前にチャットで連絡くれる
  • Lpicなどのように、解答したかどうかを一覧で見ることが出来ないので、解けた問題にフラグ立てておくと良さそう。
  • 問題ごとにcontextを変更する必要があった

3時間ぶっ通しで頭を使いまくって頭痛がする中終わりました。。。
考えている時間より、手を動かしている時間の方が圧倒的に多かったです。ていうか考えている暇がない・・・

■試験結果

3日後くらいにメールで結果が届き、残念ながら64%でfailedでした。
合格ラインは74%でした。

■反省

クラスタデプロイ系、クラスタのトラブルシュート系の問題が全然できていなかったので、その点が厳しかったのかなーと思います。
手応え的には受かるか受からないか微妙なライン…て感じだったので、その感じでは受からないんだなーと思い知らされました。。

あとは、基本的なリソース以外はフワッとした理解しかしていなかったので、その辺が弱かったのかなと思いました。

勉強方法(2回目/CKA改訂後)

2回目は1回目の試験の手応え、結果からわからなかった問題の解き方と、
基礎的なリソースの学び直しということで完全ガイドを読みつつ理解を深めました。
udemyは先に行った通り講座は全て英語なので、英語を大学受験以降ちゃんとやっていなかった私としては
日本語のしっかりしたテキストは非常に助かりました。

完全ガイドは全くの初心者の方には詳しすぎるため、情報の取捨選択をできるくらいに勉強したタイミングで
読み始めるのが良いかもしれません。

  • udemyのCKA対策講座

www.udemy.com

www.amazon.co.jp

2回目受験/結果/反省

■試験資格

最初に購入したバウチャーの再試験資格を使って受験しました。
再受験の方法がパッとわからず地味に詰まっていたのですが、意外と書いている方が少なく・・・
やり方がわかったらすんなり行けたので、書いておきます。

linux foundationのダッシュボードのcertification > Resume
左のmenuのドロップダウンから「exam」を選ぶと再試験のスケジューリングができるようになります。

最初linux foundationのダッシュボードを全然使わず、psiでだけやるものだと思っていたので
再試験の予定ができず困っていました・・・

■試験日

2020/10/31に受験しました。

■試験場所

1回目と同じく自社の会議室を借りて受験しました。

■試験準備

1回目と特に変わらず。

■試験当日

例によって箇条書きで気になったことを。

  • 試験時間は2時間
  • 画面共有がchromeでどうやってもできなくて困った→その場でvivaldiインストールしてなんとか対応できた、試験時間が1時間くらい遅れた

→特にこだわりない人は複数ブラウザダウンロードしておいた方がいいかも?

  • 何か怪しいものがないか確認されるが、モニターやホワイトボード、プラスチックパーテーション等は特に指摘されない
  • 一定時間ごとに手をあげてくださいという指示がきます、カンニング防止?
■試験結果

シルバーウィークと被ったからなのか、結果が出るまでに2週間ほど時間がかかりました。
結果はなんと合格ライン66%中19%でfailed。。。
個人的にかなり手応えがあったつもりだったので残念でした。

■反省

思ったより全然できていなかったことの理由をいろいろ考えましたが、
一番は分野の採点基準が変わったことかなと思います。(トラブルシュート系の問題の配点が30%も占めるようになった)
あとは試験時間が2時間に減ったのに問題数と1問のボリューム感があまり減っていないことで
結構焦ってケアレスミスがあったのかなーというところですね。
試験問題改訂前よりもコマンド一つ一つに求められる速さが早くなっている気がしました。
細かく時間を削れるので、やっぱりコマンド慣れしておくこと、略称を覚えておくこと、エイリアスをうまく使うこと(defaultネームスペース以外での作業がメインになる問題は、エイリアスをkubectl -n namespaceで登録しておくと楽です)が重要だと感じました。

振り返り/これからの受験に向けて

1年ほどのんびりCKAを受験してきて、学んだことやよかったなということを箇条書きにしていきたいと思います。

  • udemyの講座は買って本当によかった。テキストをただ読むのが苦手なので、ハンズオンがあると手が覚えるのでとてもよかったです

 問題内容も試験内容に直結するものが多かったのでこれは本当にお勧めです。

  • kubernetes.ioのドキュメントは一通り確認して、よく使うページはブックマークしておきましょう。(当日はkubernetes.ioであればブックマークから飛んでも怒られなさそうです)
  • 勉強以外の準備が意外と必要な場合がある(顔写真つき証明書の用意や会議室の用意など)
  • 結構シビアな試験。完全なハンズオン形式なので手の速さは絶対あった方がいい

 →ぺーぺーエンジニアだったのでNWやサーバーの基礎知識がなく、そう言った点で試験中困ることもわりとありました。
  コマンド等滑らかに打てた方がいいので、Lpic level1くらいは事前知識としてあった方がいいかも

  • 試験中に使うマニフェストは絶対公式からコピーか、dry-runで作成したものを公式ドキュメントを参考に編集していく方法が良いと思います。

 インデントやスペルミスでハマるのはとてももったいない・・・

実は今週の日曜にまた受験予定なので、頑張ってきたいと思います。
3度目の正直…!


今回は時間がなく書けませんでしたが、受かった後にudemyの問題のクセ(一部解けない問題がある)の記事など書いてみたいと思っています。
ここまで読んでいただきありがとうございました。

ここから追記:

勉強方法(3回目/CKA改訂後)

3回目は問題の傾向や基本のリソース、コマンド等は押さえていたため
2回目の試験で答えられなかった苦手問題のリソースについて公式ドキュメント・完全ガイドで復習しつつ
udemyの模擬試験を解いて回答作成のスピードを早めていくことに専念しました。
具体的に勉強しなおしたのは以下。

Ingress
・NetworkPolicy
・etcd pod backup,restore
・side car container
・node trubleshoot

  • udemyのCKA対策講座

www.udemy.com

3回目受験/結果/反省

■試験資格

昨年と同じくlinux foundationのサイバーマンデーで試験資格を購入しました。

■試験日

2020/12/27に受験しました。

■試験場所

年末だったりコロナだったりで外出が嫌だったので自宅の近所の会議室を借りました。
移動時間が少ないことは意外とストレスが軽減するものですね。
ギリギリまで勉強できますし。

■試験準備

1回目と特に変わらず。

■試験当日

基本は2回目と同じです。

  • 試験時間は2時間
  • 今回はキーボードを使用して受験してみました。特に問題なかったです。
  • 前回は頻繁に「手をあげて」という指示をされましたが、今回は1回もされませんでした…試験官による?
  • 初めてトイレ休憩を入れましたが特に問題なしでした。
  • 今回は最後に時間の余裕があったので初めて見直しをすることができました。途中までですが…
■試験結果

36時間以内に結果が発表され合格でした!



■反省

私は合格まで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の勉強の為に始めた

↓こちらの本のハンズオンを実践中、個人的に詰まった箇所と原因について

書いていきたいと思います。


gihyo.jp


全然関係ないですがDockerのくじらくんってかわいいですよね。

f:id:siromamex:20200125221419p:plain
moby dock
 

詰まったところ①

最初に詰まったのは2.5の「Docker Composeでマルチコンテナを実行する」

というハンズオン。

 

内容的には、Jenkinsのイメージを使ってmaster,slaveのコンテナを

docker-compose.yamlで立て、JenkinsのGUIを使用して

masterからslaveにSSHログインできるように設定するというもの。

 

こちらは、

プラグインが正常にインストールされず、slaveへのSSH設定ができない」

と言う問題と、

「なんとかプラグインを導入し、SSH接続の設定はできたものの

 接続が行われない」

という二つの問題が起きました。

 

一つ目の問題は一応一人で解決できましたが、二つ目で心が折れたため

同僚に頼って問題を解決してもらいました。

 

こちらの問題については、以下の記事にまとめられています。

 
qiita.com


 

自分で問題解決できるような何度エラーが起きても折れない強い心と知識が欲しいですね。。

 

詰まったところ②

次に詰まったところは、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の書き方が間違っていたようです。


今回のキモはこちらのサイトの以下の部分です。

manpages.debian.org

「第 6」フィールド (行の残りの部分) には実行されるコマンドを指定する。
その行のコマンド部 (改行文字または % 文字まで) が /bin/sh
(またはその crontab ファイルの SHELL 環境変数で指定されたシェル) によって実行される。


 最初はてっきりタブとスペースの置き方をミスっていたのかと思いましたが、
crontabを書くときはどこまでが実行コマンドかを判断させるために改行文字か%をコマンドの後ろに置く必要が
あったみたいです。


以前職場で、あるサーバのバックアップをとるためにバックアップシェルをcronで日次実行しようとしたとき、
何故か次の日実行されておらず、原因が分からずじまいでしたが
やっとわかりました。よかったよかった。

まとめとおまけ

一旦今日はここまでです。
12月上旬から始めてハンズオンにめちゃくちゃ時間がかかっている理由は、
こちらが原因です。

こないだやっとハンズオンで使用するすべて(?)の資材を作成し終わったので、
今日からやっとハンズオンを再開し始めた次第です。

資材を作るのがめんどくさい!という方は以下のgithubリポジトリを公開しておりますので
よろしければどうぞ。

github.com


くじらくんに癒やされながら残りのハンズオンも頑張っていきたいと思います。


おしまい