k8s の volume のパーミッションと進数

k8s のボリュームのパーミッションでハマったのでメモ

ある volume の yamlパーミッションで "420"という見慣れない数字が並んでいた。

 

Linuxパーミッションは8進数である

k8s のボリュームのJSON は 8進数が許容されていない。

・なのでパーミッションが10進数が表示されていた、というカラク

・8進数:644 = 10進数:420

 

参考:

`kustomize` changed my file mode from `mode: 0755` to `mode: 493` in configMap volume · Issue #1790 · kubernetes-sigs/kustomize · GitHub

---

0755 in octal becomes 493 in decimal, the two are equivalent.

---

Kubernetesでコンテナに設定ファイルを追加したい場合にDockerイメージを作成せずに運用していくtips – PSYENCE:MEDIA

Unity 次のシーンに移動するスクリプト

やりたいこと

・ステージ1->2、ステージ2->3などシーンの移動をゲームで実装したい。

 

手順

1.シーンを作成

自分の場合は複製したので、Assets->対象シーンを選択->Edit->Duplicate

2.シーンを Build Setting に登録

File->Build Setting

3.次のシーンに移動するスクリプトを実装するため、以下構文を追加

using UnityEngine.SceneManagement;

//NextStage関数をボタンで実装する

public void NextStage()

    {

        int index = SceneManager.GetActiveScene().buildIndex;

        index++;

        SceneManager.LoadScene(index);

        Debug.Log(index);      

    }

4.シーンのUI->Buttonでボタンを作成、OnClick関数としてNextStage関数を登録する

(詳細は以下のサイトが参考になります)

 

参考

unityで複数のステージレベルを管理する方法 - Qiita

【Unity】 OnClickの一覧に関数が出てこない

 

Unity 別スクリプトの変数を変更する

大変基礎的なことかと思いますが、ハマったのでメモ。

 

### 以下の項目を実現したい

項目1.シーンが遷移しても変数(数字)を維持したい

項目2.その変数をリセットする処理も加えたい

項目3.上記1と2でスクリプトを分けたい

 

### 実現方法

項目1.スクリプトA で以下のように記述

`public static int 変数名  = 数字; //シーンが遷移しても変数維持

項目2.スクリプトBで以下のように記述

`スクリプトA.変数名 = 0; //リセット。スクリプト名を頭につけることで、別スクリプトの変数を取得できる。

(小ネタ)Private ACRからPull する際の注意点

パブリックな通信を閉じた ACR に対して、App Service Container のイメージのプルが失敗したので、備忘録。

 

・ACR をプライベートエンドポイントと統合

・App Service をVNET に統合

これに加えて、WEBSITE_PULL_IMAGE_OVER_VNET=trueという設定を入れる。

こうする事で、App Service へのプルがパブリックから VNET 経由に変わる。

 

4. Pull from private registry
https://azure.github.io/AppService/2021/07/03/Linux-container-from-ACR-with-private-endpoint.html#3-create-network-integrated-web-app

--抜枠--

Images will by default be pulled over public route, but by setting WEBSITE_PULL_IMAGE_OVER_VNET=true, you tell the platform to use the virtual network integration for pulling the image:

----------

 

以上

Microsoft 認定試験 SC-900 合格メモ

Microsoft 認定試験 SC-900 に合格しました。

f:id:justaday:20220319221111j:image

試験概要:

セキュリティの基礎用語(例.認証と認可の違い)や Microsoft 製品群 (Microsoft 365、Azure、各種 Defender と名の付く製品等) の超概要が問われます。

試験 SC-900: Microsoft セキュリティ、コンプライアンス、ID の基礎 - Learn | Microsoft Docs

 

所感:

AZ-900: Microsoft Azure Fundamentals のセキュリティ版試験というイメージだと思いました。

各サービスの操作方法や設定に関する質問は無く、あくまで何をするサービスなのかという概要を問われます。

Microsoft 製品に馴染みのない方でも勉強すれば十分取得可能だと思います。

 

勉強方法:

1週間くらいこの SC-900 の問題集をひたすら解きました。

Free Hub of Actual IT Exams Certification Q&As | ITExams.com

 

学んだこと:

普段セキュリティ関連の業務をしていないので、こんなドキュメントがあるのかという気づきがありました。

例えば、セキュリティ戦略を考える上で考慮すべき事項を記載した 「Microsoft Azure Well-Architected Framework」 や Microsoftクラウドサービスの監査レポートをまとめた 「Service Trust Portal」 は何かの折に使えるかもしれません。

Microsoft Azure Well-Architected Framework - Azure Architecture Center | Microsoft Docs

Service Trust Portal

 

以上

 

AKS の AAD 統合と kubelogin について

AKS を Azure AD 統合すると、kubectl 接続に Azure AD 認証させること可能。

Azure AD 認証を サービスプリンシパル で行う場合は、kubelogin を利用する。

 

Azure Kubernetes Service で Azure AD を使用する - Azure Kubernetes Service | Microsoft Docs

--抜枠--

継続的インテグレーション パイプラインなど、現在 kubectl で使用できない非対話型シナリオがいくつかあります。 kubelogin を使用して、非対話型サービス プリンシパル サインインでクラスターにアクセスできます。

---------

 

通常の kubectl コマンドでの認証はブラウザでの device code 認証を利用する。

しかし、メールアドレスを持たないサービスプリンシパルはこの認証に対応していないため、kubelogin が必要だと思われる。

f:id:justaday:20220211074622p:plain

f:id:justaday:20220211074433p:plain

 

kubelogin での利用で「非対話型」(non interactive)というのがポイントである。

非対話多型と対話型で kubelogin は手順が異なるため。

なお、Azure Cloud Shell から手順を行えることを確認した。

 

以下の情報の手順についてメモを記載する。

GitHub - Azure/kubelogin: A Kubernetes credential (exec) plugin implementing azure authentication

 

1.サービスプリンシパル作成

az ad sp create-for-rbac --skip-assignment --name myAKSAutomationServicePrincipal

 

以下の様に出力される。

appId や password を後ほど利用する。

{
  "appId": "<spn client id>",
  "displayName": "myAKSAutomationServicePrincipal",
  "name": "http://myAKSAutomationServicePrincipal",
  "password": "<spn secret>",
  "tenant": "<aad tenant id>"
}

 

2.この SP を AAD セキュリティグループに追加した上で、そのグループのオブジェクト ID を元に AKS クラスターを作成する。

Azure Kubernetes Service で Azure AD を使用する - Azure Kubernetes Service | Microsoft Docs

 

サービスプリンシパルやグループにはkubectlできるAzure RBAC権限も付与すること。

 

3.rolebinding 作成とそのための SP のオブジェクト ID 表示は不要。

AAD 統合の AKS クラスターでは自動で作成されるため。

 

Azure AD と Kubernetes RBAC をクラスターに使用する - Azure Kubernetes Service | Microsoft Docs

--抜枠--

Azure AD でグループとユーザーの例が作成され、リソースを作成および表示するために適切な権限を付与するため AKS クラスター内に Role と RoleBinding が作成されます。

----------

 

4.kubeconfig による接続と kubectl コマンドの実行

※export で appId と password を環境変数で渡すことで、サービスプリンシパル認証が可能。

※kubeconfig のパスは Azure Cloud Shell の場合

 

export KUBECONFIG=~/.kube/config

kubelogin convert-kubeconfig -l spn

export AAD_SERVICE_PRINCIPAL_CLIENT_ID=<spn client id>
export AAD_SERVICE_PRINCIPAL_CLIENT_SECRET=<spn secret>

kubectl get no

 

正常に構成が正しければ、Kubectlコマンドが通る。

 

以上

Azure 仮想マシンの再適用

仮想マシン (VM) や AKS ノードが開始中や実行中にならない状態でハングしている時の対応策のメモ。

 

<事象>

アクティビティログを見ると、VM の起動時に「失敗」が記録されていた。

文字通り、VM の起動に失敗している様子。

Azure Virtual Machines の状態と課金状態 - Azure Virtual Machines | Microsoft Docs

--抜枠--

仮想マシン リソースに対する最後の操作が成功しませんでした。

----------

 

<対応策>

VMの「再適用」を試す。今回はこれで復旧した。

※「再適用」ではAzure のホストサーバー側で管理されている情報と、VM リソース側の情報を一致させることができる。

 

Azure 仮想マシンにおける操作 (再起動、停止/起動、再デプロイ、再適用) について | Japan Azure IaaS Core Support Blog

--抜枠--

再適用とは、同一物理ホスト サーバー内で リソースの あるべき状態 (Goal State) の情報を、リソースの実体にもう一度適用させる操作です。 何らかの理由でリソースの実体が Goal State の状態に遷移ができずエラーになってしまった変更処理に対して、もう一度同じ Goal State の情報を流し込む (適用する) ことで、前回の変更処理をやり直すことにより、仮想マシンの実体の状態と Azure 基盤側で保持している Goal Stateとの状態が不一致となっている状況の修正が試みられます

----------

 

少ないリスクとの事だが、再適用の際にVM 再起動が走る可能性あり。

Windows VM 拡張機能のエラーのトラブルシューティング - Azure Virtual Machines | Microsoft Docs

--抜枠--

再適用自体では VM は再起動されず、また再適用を呼び出しても大抵の場合は VM が再起動されることはありませんが、再適用によって新しい目標状態がトリガーされたときに VM モデルに対する他の一部の保留中の更新が適用され、他の変更で再起動が必要になるという非常に小さなリスクがあります。

----------