Cloud

先週にgoogleから対処必要ってメールが来た。 せっかく覚えたのに、GCR(google cloud registry)があと1年でフェードアウトするから、さっさとGAR(artifact registry)へ引っ越せってさ。 Container Registry の非推奨 | Container Registry documentation | Google Cloud cloud.google.com 非推奨にはなってるけど、すぐには使えなくなるわけじゃなさそう。 こういう響きは、すぐになくなっちゃう可能性もあるのかなぁ。 気持ち悪いから引っ越しちゃう。 dockerイメージをコピーする方法もあるみたいやけど、GCRからローカルにpullしてGARへpushするかな。 それをGKEで動かしてみる。 前にローカルPCで作ったイメージをGCRに登録してGKEで動かしたから、その材料を使う。 GCP gkeのメモ2(gceでpythonサンプルアプリをビルドし、google cloud registoryにpush/pullしてgkeでも動かす) | ギャバンITサービス gavann-it.com VMイメージ壊さずに残ってたかな。 GARを用意 料金の確認 もちろんgoogleは商売としてサーバを貸してくれる。 まずは料金確認。 料金 | Artifact Registry | Google Cloud cloud.google.com 今の環境やと0.5GBまで無料、ネットワークは同じリージョンなら下りは無料、上りは全部無料、ストレージ使った分がかかるってことかな。 ま、練習やから今はあんまり気にしない。 リポジトリ作成 docker扱える標準リポジトリを作ってく。 標準リポジトリを作成する | Artifact Registry documentation | Google Cloud cloud.google.com gcraneってツールを使ってコピーすることもできるらしい。 一回しか使わないツールは使わない。 セットアップ方法も書いてある。 標準リポジトリへの移行 | Artifact Registry documentation | Google Cloud cloud.google.com ちゃんと動きを確認して使いましょ。 APIの有効化 GAR使うためのおまじない。 GCRからローカルPCにpull ローカルPCのイメージをカラにする 前に作ったイメージを確認ね。 ...

業務でmysql8をGKEで扱いそうになってるから、何か練習できる材料ないかなぁって探してた。 GKEでwordpressとmysqlやってみる。 だいたいのやり方はこのへんで調べてみた。 KubernetesでWordPress構築をやってみた。運用費は月額4000円ほど。 #GoogleCloud - Qiita qiita.com GCP GKE(Kubernetes) WordPressセットアップ│システムガーディアン株式会社 sys-guard.com WordPress | Google Cloud cloud.google.com なるほど、できそう。 cloud sqlじゃなくてmysql8のコンテナでやる wordpressは最新で6.2 ディスクはvmで使う普通のものを割り当ててマウント ついでにmac13にgcloud入れてgke扱えるかもやってみる。 少しナメてかかってたけど、やってみたらwordpressの設定でつまづいた。 gitでダウンロードしたyamlは書き足さなアカンかった。 クラスタもPodも何回か作り直したから、ログにあるPodの物理名はいろいろ混じってる。 mac13にgcloudのセットアップ ローカルのmac13からやってみる。 dockerはもともとlinuxの技術だったはず。 macはコンテナとか扱えないはずなんやけど、docker desktopとかrancher desktopとかあるらしい。 自分は元々linuxサーバでコンテナ取扱いするから、macにdocker入れる必要なくて、ubuntuのvmの中で環境作ってる。 GKE取扱いするのはmac13でもいけるのでgcloudとkubectlをインストールする。 gcloudの入れ方は普通にgoogleのドキュメントにある。 gcloud CLI をインストールする | Google Cloud SDK Documentation cloud.google.com ダウンロード まずは材料のダウンロードとtar展開。 1 2 3 4 5 6 7 8 9 10 nari@gvisMac13 gke-wordpress % tar xzf ./google-cloud-cli-426.0.0-darwin-x86_64.tar.gz nari@gvisMac13 gke-wordpress % ll total 269184 -rw-r--r--@ 1 nari staff 119M 4 23 06:57:15 2023 google-cloud-cli-426.0.0-darwin-x86_64.tar.gz drwxr-xr-x 21 nari staff 672B 4 23 06:58:34 2023 google-cloud-sdk/ nari@gvisMac13 gke-wordpress % du -shc * 131M google-cloud-cli-426.0.0-darwin-x86_64.tar.gz 541M google-cloud-sdk 672M total nari@gvisMac13 gke-wordpress % インストール gcloudをインストールしてみる。 そやけど、ログ長いなぁ。 ...

GCRを業務で扱うことになったのでやってみる。 GCRってのはgoogle container registoryっていうdocker image置き場。 自分のプロジェクトの中でのみ公開したいときに使うみたい。 ビルドはローカルPCのdockerでやってイメージ作ってから、GCRへ認証を通しておいてdocker pushすることでイメージ作れる。 GCRに作ったイメージはGKEのポッドに展開して動かせる。 GCR(google container registory)はGAR(google artifact registory)に移ってくのかも？ クイックスタート: Docker コンテナ イメージを Artifact Registry に保存する | Artifact Registry documentation | Google … cloud.google.com まぁええ。やってみよ。 参考にさせてもらったページは、先にcloud source repositoriesへ登録してるところもあったから、ついでにやってみた。 普段使ってるGCPのプロジェクトとは別枠でやってみた。 仮想マシン作成 マーケットプレースから流用して仮想マシン作る。 vcpuとメモリは予算に応じて。自分は4コア16GBメモリHDD50GBで作った。 無料枠やからこれぐらいでええ。ディスクを多くとったのは後でdocker入れたいから。 ファイアウォールで80と443のポート開けとく設定も入れとく。 起動してコマンドライン使えるまで1分。 めちゃ楽。 aptしてgit入れる rootユーザになって以下を動かす。 1 2 3 4 apt autoremove apt clean apt update apt upgrade 保留のパッケージが残ることもあるけど、更新対象がなくなるまで動かす。 全部で２回動かせばいい。 途中で確認メッセージが出ることあるけど、全部「承認」とか「OK」でええ。 ...

dockerはlinuxに入れてもう5年ぐらい使ってる。 gkeを業務で扱うことになったのでやってみる。 gkeではdocker使わなくなったってどっかで見た。 dockerとは違うところもあるんやろけど楽しみ。 ググるとサラっとやってるページあったので参考にさせてもらった。 作者さんありがとう。 GKE Autopilot上にNginx環境を構築 #GoogleCloud - Qiita qiita.com gkeでapi有効化とクラスタ作成 「kubernetes engine」⇒「クラスタ」を選ぶ。 初回はAPIを有効化する。 クラスタの基本 GKE Autopilotの「構成」をクリックする。 クラスタに名前つけて使いたいリージョンを選ぶ。 ネットワーキング 一般公開クラスタが選択できていることを確認してそのまま次へ。 詳細設定 特に変更せず次へ。 クラスタ作られたことの確認 確認と作成の画面もそのまま次へ行く。 「ステータス」がクルンクルン回るので、終わるのを5分ほど待つ。 後で書いとくけど、ここがうまく行くのに実際はトラブった。 うまく行くとステータスが緑色のチェック入りで表示される。 nginxをデプロイ やっとアプリケーション設置。 あんまり設定することはないけど、「選択」ってするとイメージ指定できるんやろ。 他にどんなイメージ使えるんか nginx以外を選択するときはArtifact Registry APIってのを有効にせなアカンのか。 今度また使うから、有効にして一覧見えるようにできるか。 認証情報って作らなアカンの？ って、下のほう見たらgkeで実行するアプリには必要なしやでって書いてある。 時間なくなったから、いったんこのへんまでにしとこ。 nginx普通に使えるようにしよか。 使えるようにする 名前はデフォルトのまま。クラスタも指定できてるのを確認。 いきなり公開するのはやめとこか。 ちゃんとデプロイできるか見てからやね。 さぁ行ってみよっか。 なんやねん、Unschedulableってあるやん。 リソース確保にたぶん失敗したんやろなぁ。少し待ったら自律回復してくれるかも。 5分ほどタバコ休憩してからワークロード見たら、シレっと動いてた。 公開されたものが見えるか確認 公開してみたろやんけ。普通にhttpでいってみ。 ...

OSをテキトーに選んでEC2インスタンスを作ってしまうとディスクサイズが小さすぎて後で苦しむことも。 他に、dockerは/var/あたりを使うのでイメージとコンテナの保管領域が足りなくなったり。 そんなときのためのディスク拡張。 パーティションの確認 拡張したいパーティションを目視で確認しておく(ここではルートパーティションの/dev/xvda1)。 EBS IDの確認 インスタンスを停止させてコンソールに戻り、拡張したいデバイス（ここでは/dev/xvda）の青い文字をクリックしてEBS IDを確認する。 スナップショットの作成1 左ペインの「ボリューム」をクリックし、確認しておいたEBS　IDのデバイスをクリックして「スナップショットの作成」を選ぶ。 スナップショットの作成2 名前を入れて作成し、左ペインの「スナップショット」を選んで、ステータスがPendingからCompleteになるまで待つ。 スナップショットの作成3 8GBで作ったものを利用率約29%（2.2GB）のものでもCompleteになるまで5分以上かかった。 スナップショットからボリューム作成 スナップショットがCompleteしたら「ボリューム作成」を選択する。 ボリュームサイズの入力 今回は8GBを100GBにしたいので100を入力。 旧ボリュームのでアタッチと新ボリュームのアタッチ 左ペインの「ボリューム」から、古いボリュームをデタッチし、新しいボリュームをアタッチする。 アタッチ先選択 アタッチ先は候補が出てくるので選択する。 デバイス名は元の名前と同じものにしておかないとインスタンスの起動エラーになってしまう。 新ボリューム使ってEC2インスタンスの起動 左ペインの「インスタンス」から対象のEC2を選んで、スナップショットから作成したボリュームがルートデバイスに組み込まれていることを確認して起動。 EC2インスタンスの起動確認 /dev/xvdaが100GB(df結果では99GB)になり増えていることと、このルートデバイスからOSが起動できサービスも動いていることを確認。