/// BANGBOO BLOG ///

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30

July 24, 2022

Docker
どこでビルドしてもデプロイしてもImmutableインフラ(不変の)なので変更したい場合はDockerfileの方を変える
コンテナはOS上のDockerEngine上に配置する(コンテナは複数配置できる、Dockerfileさえあれば再現可)
DockerfileでなくてもDockerイメージでもいいが、Dockerは可搬性をもたらすのである
 なおVMはOSをもシミュレート
1部: はじめに|実践 Docker - ソフトウェアエンジニアの「Docker よくわからない」を終わりにする本 (zenn.dev)
2部: Dockerfile の基礎|実践 Docker - ソフトウェアエンジニアの「Docker よくわからない」を終わりにする本 (zenn.dev)
3部: Docker Compose|実践 Docker - ソフトウェアエンジニアの「Docker よくわからない」を終わりにする本 (zenn.dev)
 Dockerのチュートリアル - とほほのWWW入門 (tohoho-web.com)
 Dockerコマンド - とほほのWWW入門 (tohoho-web.com)
  コンテナ設計方針をまとめてみた - Qiita
  社内のDockerfileのベストプラクティスを公開します│FORCIA CUBE│フォルシア株式会社
  Docker完全に理解した | IIJ Engineers Blog
 ボリュームマウント=DockerEngine上にボリュームを作りコンテナにマウント(操作が面倒で仮使用や永続ファイル用)
 バインドマウント=LinuxOS上のファイルやディレクトリをマウント(ファイル編集が多い場合)
 dockerfile(イメージを作る)、docker compose(yamlで一括でコンテナ/nw/volを作る)
  dockerfile: dockerイメージを作る→runでコンテナ(アプリ)になる
  docker composer: コンテナを作る、NWやボリュームも作る→1台にまとめる
   マニフェスト: k8sを作る→複数台になる
    Dockerfileによるビルド - とほほのWWW入門 (tohoho-web.com)
    Docker Compose - とほほのWWW入門 (tohoho-web.com)

■Dockerインスコ
/// BANGBOO BLOG /// - GCP script ここの下の方に記載あり
docker --version
who 誰がログインしているか
sudo gpasswd -a [ユーザ名] docker dockerグループへ追加?

■Docker Engine起動
sudo systemctl start docker これ要る?

■オプション
-i キーボードを繋ぐ
-t 特殊キーを使用可能にする
-e 環境変数名=値(複数記載可能)
--net=ネットワーク名
-v ${pwd}:/app はOSローカル環境とコンテナ内のディレクトリを同期
-p, -public 80:8000 ポートの紐づけ
-d, -detach バックグラウンド実行(デタッチ)
-rm コンテナ実行後にコンテナを自動削除する(イメージは残る)
-dit  とまとめられる

■操作コマンド
docker images リスト
docker tag [イメージID] img_unco:latest 名前がつかない場合
docker rmi [イメージID]  削除
docker ps -a コンテナ一覧
docker container ls コンテナのステータス確認
docker rm [コンテナID] 削除

■起動
httpd3つを1つのイメージで建てられる(以前はdocker runだった)
docker container run --name コンテナ名001 -d -p 8081:80 イメージ名httpd
docker container run --name コンテナ名002 -d -p 8082:80 イメージ名httpd
docker container run --name コンテナ名003 -d -p 8083:80 イメージ名httpd

■仮想NW
コンテナ間をつなぐ(ネットワークタグ名で紐づける感じ)
1)ブリッジネットワーク(デフォルト
 同一の Docker Engine 上のコンテナ が互いに通信をする場合に利用する
 デフォルト:
  全てのコンテナ間をリンクする操作が必要
  コンテナ間の通信は IP アドレスで
 ●(コレ使う)ブリッジネットワークを定義し作成:
  相互通信は同じネットワークを割り当てるだけ
  コンテナ間でDNS解決される
  ネットワークでコンテナは隔離され隔離度が上がる
2)オーバーレイネットワーク
 異なる Docker Engine 上のコンテナ が互いに通信をする場合に利用

docker network create ネットワーク名net001

docker container run --name mysql001 -dit --net=net001 ~~~ イメージ名mysql
docker container run --name wordpress001 -dit --net=net001 -p 8085:80 -e WORDPRESS_DB_HOST=mysql001 ~~~ イメージ名wordpress

Docker仮想NW一覧
docker network ls
仮想NWの確認
docker network inspect net001

コンテナ間はservice_nemeで通信し、コンテナ名ではない
http://unco-sv:8000 で通信できる
各コンテナで同番ポートを使っていても問題はない
docker info プロキシ等が確認できる
.docker/config.json でプロキシやプロキシを使わないnoProxyを設定

■停止
docker stop コンテナ名
docker rm コンテナ名
docker network rm ネットワーク名

■コピー OS⇔コンテナ
docker cp コピー元 コピー先
例)docker cp /home/a.txt コンテナ名:/app/

■ボリュームのマウント
データをコンテナ内に置くとコンテナが消えるとデータも消えてしまう
永続化1)ボリュームマウント:DockerEngine上
永続化2)バインドマウント:OS上
永続化3)一時メモリマウント:(tmpfs)

■バインドマウント
docker volume create ボリューム名vol001
docker run --name コンテナ名httpd001 -d -p 8080:80 -v /home/a:/usr/local/apache/htdocs イメージ名httpd (OS側パス:コンテナ側パス、コンテナ側のパスをどこにすべきかはDockerイメージのドキュメントを見よ)
docker volume inspect vol001 (確認できる)
docker volume rm vol001

ホストディレクトリ共有ともいう
コンテナはrootで動作しているものが多く
ホスト共有しているDir/Fileにコンテナから変更するとrootで変更しPermissionが変わるそのためホストディレクトリ共有は本番に向かない

■ボリュームマウント
ちょい面倒らしいのでバインドマウントでいいのでは?
docker volume create ボリューム名vol001
docker run --name コンテナ名httpd001 -d -p 8080:80 -v ボリューム名vol001:/usr/local/apache/htdocs イメージ名httpd (OS側パス:コンテナ側パス)
docker volume inspect vol001 (確認できる)
docker volume rm vol001

Dockerボリューム共有ともいう
コンテナが削除されても明示的に消さない限り保持される
永続化したいパスを指定してマウントできる
(通常コンテナ内で作成されたデータは永続化しない)

■揮発的データを退避
docker cp コンテナ名:ファイルパス ホスト側退避パス
 docker cp test-db-a:/opt/test.txt /tmp/config
消えるファイルをホスト側に退避したいときのコマンド

■ボリュームマウントの確認やOS側にバックアップ
アプリコンテナとは別のshellコンテナを用意してlsしたりtar.gz等する
Apacheコンテナ <-> vol001 <- Linuxコンテナ -> vol002バックアップ
マウントを2つ(DockerEngine上のマウント、OS上のマウント)
tar.gzコピーでDockerEngine上の指定フォルダにコピーするが其れはOS側にもマウントされている、最後のドットも要る
イメージは軽量Linuxのbusyboxを使用
docker run --rm -v vol001:/usr/local/apache/htdocs -v /home/b:/tmp busybox tar CXvf /tmp/bjk.tar.gz -C /usr/local/apache/htdocs .

■ログ
docker logs コンテナ名
docker logs -f コンテナ名 追従確認
docker exec -t コンテナ名 /bin/bash ログファイル等はこれで入り確認

■Appコンテナ(PHP)
docker container run \
    --name app \ コンテナにappと名付る
    --rm \ コンテナ停止時に自動削除
    --detach \ バックグラウド実行
    --interactive \ 対話可能なセッションに
    --tty \ コンテナとのTTY接続しコマンド出力可
    --mount type=bind,src=$(pwd)/src,dst=/src \ osにバインドマウント
    --publish 18000:8000 \ ポートマッピング
    --network docker-sample-network \ 仮想NWに割り当て
    docker-php:app \ Dockerイメージの名前とタグ
    php -S 0.0.0.0:8000 -t /src コンテナ内で実行するコマンド

※永続化バインドマウントos上
ホストマシンのディレクトリをコンテナ内のディレクトリにバインドマウント。ホストマシンのカレントディレクトリ($(pwd))の"src"ディレクトリが、コンテナ内の"/src"ディレクトリにマウントされます

※ポートマッピング
-p, --publishがコンテナのポートをホストマシンに公開するオプション
ホストマシンの18000ポートを通じてコンテナの8000ポートにアクセスさせる
ブラウザからhttp://localhost:18000 でphpにアクセス

※起動コマンド
PHPのビルトインウェブサーバを起動し、IPアドレス "0.0.0.0" およびポート "8000" でリクエストを受け付け、コンテンツを"/src"ディレクトリから提供します

■コンテナの詳細情報の確認
docker container inspect app

■DBコンテナ(MySQL)
docker container run \
 --name db \
 --rm \
 --detach \
 --platform linux/amd64 \
 --env MYSQL_ROOT_PASSWORD=rootpassword \
 --env MYSQL_USER=hoge \
 --env MYSQL_PASSWORD=password \
 --env MYSQL_DATABASE=event \
 --mount type=volume,src=docker-db-volume,dst=/var/lib/mysql \
 --mount type=bind,src=$(pwd)/docker/db/init.sql,dst=/docker-entrypoint-initdb.d/init.sql \
 --network docker-sample-network \
 --network-alias db \
 docker-db:db

※仮想NWでのエイリアス名
dbと名付ける

■コンテナの疎通の確認
$ docker container exec --interactive --tty app ping db -c 3
appコンテナがdbに疎通できるかping

■アプリ
/// BANGBOO BLOG /// - GCP script 下の方に記載あり

■Dockerfile
ビルドしてイメージを作成
FROM イメージ名
COPY コピー元パス コピー先パス
RUN Linuxのコマンド

ENTRYPOINT イメージを実行するときのコマンド
CMD コンテナ起動時に実行する規定のコマンドを指定
 例えばこのコマンドを実行するCMDは
  $ go run /echo/main.go
  ↓空白で分割し配列化しCMD化される
  CMD["go", "run", "/echo/main.go"]
 ただCMDは下記のように実行中に上書き指定ができ echo yayの実行となる
  docker container run $(docker image build -q .) echo yay
ONBUILD ビルドが完了したときに任意の命令を実行する
EXPOSE 通信を想定するポートをイメージの利用者に伝える
VOLUME 永続データが保存される場所をイメージ利用者に伝える
ENV 環境変数を定義する
WORKDIR RUN/CMD/ENTRYPOINT/ADD/COPYの際の作業ディレクトリ
SHELL ビルド時のシェルを指定
LABEL 名前やバージョンや制作者情報等を設定
USER RUN/CMD/ENTRYPOINT実行するユーザやグループを設定
ARG docker buildする際に指定できる引数を宣言
STOPSIGNAL docker stopの際にコンテナで実行しているプログラムに対して送信するシグナルを変更する
HEALTHCHECK コンテナの死活確認をするヘルスチェックをカスタマイズする

社内のDockerfileのベストプラクティスを公開します│FORCIA CUBE│フォルシア株式会社
RUN adduser -D myuser && chown -R myuser /myapp
 (-Dはデフォルト設定で追加している、-Rは指定dir以下を再帰的に所有権変更)
USER myuser
 (以降のRUNやENTRYPOINT等のINSTRUCTIONを実行するユーザを指定)
Dockerセキュリティベストプラクティス トップ20:究極ガイド

Dockerfileの作り方を考え直したらすごく効率が上がった。 (zenn.dev)

■ビルドでイメージを作成
Dockerfileや材料ファイルのあるフォルダパスを最後に指定、-tはタグでイメージ名
docker build -t img_httpd001 ./

ビルド後にdocker runが必要
docker container run -d --name cnt_httpd001 -v ${pwd}:/app img_httpd001:latest
↓これが便利
docker container run -rm --name cnt_httpd001 -v ${pwd}:/app img_httpd001:latest

■commitでコンテナからイメージを作成
コンテナにexecで幾つかインスコする操作をしてからイメージにする等ができる
docker commit httpd001 img_httpd001

■コンテナ/イメージはDockerEngine上から移動できない
saveするとファイル化され、できるようになる
docker save -o save_img_httpd001.tar img_httpd001
 ファイルからイメージとして取り込みたいときはdocker load
 ファイル化せずにパブリックならDocker hubへ登録してもよい、プライベートレジストリを作ってもよい
  その中にそれぞれリポジトリを持つ > docker push レジストリ/リポジトリ名:バージョン

■コンテナに命令する
2つの方法がある
1)docker exec → docker container execに変わった
起動中のコンテナ内でコマンドを実行する
docker container exec [option] <container> command
ファイルを見る
docker container exec ubuntu1 cat ~/hello.txt
コンテナに接続してbashを使う
docker container exec --interactive --tty ubuntu1 bash

2)docker run に引数を付ける→ソフトウェア(apache)が動いていない状態になり改めてdocker startが必要
docker exec -it コンテナ名httpd001 /bin/bash
 apt install mysql-server など対話でコンテナにインスコできる
exit 抜ける

■Docker compose
docker runコマンドの集合体、コンテナ等作って消すだけ(k8sはコンテナ等を管理する)
以前はdocker-composeコマンドで別ツールだったが今は統合済み
フォルダに1つだけdocker-compose.yml
基本はdocker runを実行せずにdocker composeしたい
手順は、1)Docker run方法で一応の検討>2)docker-compose.ymlの記述>3)docker composeコマンドの実行

docker run~~に対するdocker-compose.ymlとdocker composeコマンド の対比
1)docker run --name cnt_wordpress001 -dit --net=net001 -v wordpress001vol2:/var/www/html -p 8080:80 -e WORDPRESS_DB_HOST=mysql001 -e WORDPRESS_DB_NAME=wpdb001 -e WORDPRESS_DB_USER=wpu001 -e WORDPRESS_DB_PASSWORD=my-secret-pw wordpress
2) docker-compose.ymlの記述
version: "3"
services:
  cnt_wordpress001:
    depends_on:
      - cnt_mysql001
    image: wordpress
    networks:
      - net001
    volumes:
      - wordpress001vol2:/var/www/html
    ports:
      - 8080:80
    restart: always
    environment:
      WORDPRESS_DB_HOST=mysql001
      WORDPRESS_DB_NAME=wpdb001
      WORDPRESS_DB_USER=wpu001
      WORDPRESS_DB_PASSWORD=my-secret-pw

  cnt_mysql001:
    image: mysql:5.7
    networks:
      - net001
    volumes:
      - mysql001vol1:/var/lib/mysql
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD=my-root-pw
      MYSQL_DATABASE=wpdb001
      MYSQL_USER=wpu001
      MYSQL_PASSWORD=my-secret-pw
networks:
  net001
volumes:
  mysql001vol1:
  wordpress001vol2:

/// restartの設定値(コンテナが停止した時にどうするか?)
no =何もしない
always =必ず再起動する
on-failure =プロセスが0以外のステータスで終了したときは再起動する
unless-stopped =停止していたときは再起動しないがそれ以外は再起動する
 Bashで終了ステータスよる条件分岐 | Codebase Blog
 ※bashは前に実行されたコマンドの終了ステータスは「$?」で取得できるが慣習的にコマンドが正常終了した場合は0を返す

/// その他の定義項目
command =起動時の規定コマンドを上書きする
entrypoint =起動時のENTRYPOINTを上書きする
env_file =環境設定情報のファイルを読み込む
 他 container_name / dns / eternal_links / extra_hosts / logging / network_mode etc.

3)docker compose コマンド
 up=イメージDL、コンテナ/nw/volの作成・起動
 down=コンテナとnwの停止と削除、volとイメージは残る
 stop=削除せず停止のみ

docker compose -f /home/a/docker-compose.yml up -d
docker compose up -d --scale unco001=3 (コンテナ名はput-folder-name_unco001_1, put-folder-name_unco001_2, put-folder-name_unco001_3になる)
 -f ファイルの場所(省略でカレントパス)
 -d バックグラウンド実行
 --build コンテナ開始前にビルド
 --no-build イメージが見つからなくてもビルドしない
 -t コンテナ停止のタイムアウト(デフォ10S)
 --force-recreate 設定やイメージに変更が無くてもコンテナを再生成
 --no-create コンテナが存在していれば再生成しない
 --abort-on-container-exit コンテナが一つでも停止したら全てのコンテナを停止
 --remove-orphans 定義ファイルで定義されていないコンテナを削除
 --scale 同じコンテナを複数作る

docker compose -f /home/a/docker-compose.yml down
 --rmi {all | local} 破棄後にイメージも削除、localの時はimageにカスタムタグが無いイメージのみを削除
 -v volumesに記載されているボリュームを削除、但しexternalの指定を除く
 --remove-orphans 定義ファイルで定義されていないコンテナを削除

docker compose -f /home/a/docker-compose.yml stop
 コンテナを停止

■Docker composeはコンテナ名を勝手につける
docker-compose.yml内は下記の通り、DockerEngine上のコンテナ名は変わるがdocker-compose.yml内のコンテナ名は変わず指定できる
services:
  unco001

  unco002
    depends_on:
      - unco001
    environment:
      WORDPRESS_DB_HOST: unco001

DockerEngine上のコンテナ名は put-folder-name_unco001_1 となる
DockerEngine上で操作したいときは docker ps -a 等で実際の名前を確認して操作する

■コンテナ デバッグ
3部: デバッグノウハウ ( 番外編 )|実践 Docker - ソフトウェアエンジニアの「Docker よくわからない」を終わりにする本 (zenn.dev)

====================
基本はLinuxの機能を使っている
namespaceで分離し
ファイル構造、ユーザーID、グループID、コマンド、ライブラリなど諸々を
ラップしコンテナ化し(単一の)プロセスとして動く

Dockerがやっている仕事は少ない
区切ってコンテナ
それら仮想ネットワークで繋ぐ
ボリュームの永続化
Dockerfileでイメージからイメージを作成
Docker composeでdocker runを記述
docker execでコンテナを操作
etc.

Posted by funa : 03:46 AM | Web | Comment (0) | Trackback (0)


May 18, 2022

LPIC
Level1 Ver4.0
■システムアーキテクチャ
周辺機器のon/offや起動ドライブ検索順序はBIOS/UEFI
/proc以下のファイルによりカーネルが認識しているデバイスを確認できる
/dev以下にはデバイスファイルがある
USBはホットプラグデバイス
lsusbでUSBデバイスの情報、lspciでpciデバイスの情報を確認できる
modprobeコマンドでデバイスドライバをロード
起動時にカーネルが出すメッセージはdmesgで表示
SysVinitのシステムでは/etc/inittabでデフォルトのランレベル設定
0:停止、1:シングルユーザモード、5:マルチユーザモードGUI、6:再起動
ランレベル移行はinitやtelinit
systemdのシステムはsystemctlでサービス管理
shutdownでシステム停止や再起動

■インスコとパッケージ管理
インスコにはルートパーティション/とスワップ領域が必要
中大規模では/varや/homeと/は別パーティションが良い
/varはログやメールデータ
/homeは各ユーザのホームディレクトリで肥大化しやすい
スワップ領域は物理メモリと同程度から2倍を確保
GRUBのインスコにはgrub-install
GRUB Legacyの設定ファイルは/boot/grub/menu.lst
GRUB 2の設定は/etc/default/grub、grub-mkconfigを実行すると設定ファイル/boot/grub/grub.cfgができる
共有ライブラリはld.soによってリンクされる
実行ファイルが必要とするライブラリはlddで確認
ld.soが参照する/etc/ld.so.cacheは/etc.ld.so.confを元にldconfigで作成
Debianパッケージ管理はdpkgやAPTツールで、apt-get、apt-cache、aptitudeがある
APT設定ファイルは/etc/apt/sources.list
RPMパッケージ管理はrpmやYUM
rpmでパッケージをインスコするには-i、アップグレードには-Uもしくは-F、アンインスコには-eオプション
rmp -qはパッケージ情報の参照
YUMレポジトリ設定は/etc/yum.repos.dディレクトリ以下のファイルで

■GNU
変数名=値 でシェル変数を設定
echo $変数名 で変数の中身を確認できる
unsetで変数を削除
exportでシェル変数を環境変数に
環境変数を一覧 env や printenv
環境変数とシェル変数を一覧 set
環境変数PATHでコマンドの検索パスを定義
複数コマンドを連続実行は;で区切る
直前のコマンドが成功したときのみ次コマンド実行 &&
失敗した時のみ実行は ||
'や"の囲みは文字列として、`の囲みはコマンドと解釈
"や`の囲みの中は変数展開されるが、'ではされない
historyでコマンド履歴表示
manでマニュアル参照、1:ユーザコマンド、5:ファイルfmt、8:システム管理cmd
属性を保持したままコピーは cp -p
移動先で上書きしたい場合は cp -f、あるいは mv -f
ディレクトリ作成で必要な親ディレクトリを作る場合は mkdir -p
サブディレクトリを含めて削除 rm -r
file でファイルの種別を確認できる
シェルでワイルドカードが使える
. 任意1文字
* 直前の文字の0回以上繰り返し
[] いずれか1文字
[a-c] aからcの範囲
[^ab] aとb以外
^ 行頭
$ 行末
\ エスケープ
+ 直前の文字の1回以上の繰り返し
? 直前の文字の0回もしくは1回の繰り返し
| 左右いずれかにマッチ
コマンドの出力を別コマンドの入力化やファイル格納するにはパイプやリダイレクト
tee 標準入力をファイルに格納し同時に標準出力に出す
ファイルの表示・連結は cat
バイナリファイルを8進数法事するには od
テキストファイルの先頭表示 head、末尾表示 tail、-nで行数
tail -f でファイル末尾を継続監視
テキストファイルの列の取り出しや連結 cut や join や paste
trは文字列を置換
uniqは重複する行を1行にまとめる
xargsで標準入力から受け取った文字を引数にし与えられたコマンドを実行
grepやsedで正規表現を使う

■ファイルとプロセスの管理
gzip, bzip2, xy はファイル圧縮
unzip, bunzip2, xz(unxz)はファイル解凍
tar, cpio はアーカイブ作成・展開
chown ファイルやディレクトリの所有者設定
 ユーザは必ずどこかのグループに登録しなければならない
 一般的にはユーザ名と同じグループ名でメイングループとして登録していることが多い
 ユーザがメイン以外で登録しているグループ。複数登録できる
 ファイルやディレクトリの作成時点では所有ユーザ=作成ユーザのメイングループがそのまま所有グループとなる
  所有者をuser2に変更
  chown user2 test.txt
  所有者をuser2にグループをgroup2に変更
  chown user2:group2 test.txt
  :から書くとグループだけ変更
  chown :group2 test.txt
  ファイルのグループの調べ方
  ls -l
chgrp は所有グループ変更
chmod ファイルやディレクトリのアクセス権変更
SUIDやSGID適用のプログラムは実行ユーザに関係なく所有者or所有グループの権限で実行スティッキービットを設定したディレクトリは自分が所有するファイル以外削除不可
アクセス権
 所有者/グループ/その他
 r読み 4
 w書き 3
 x実行 1
 ナシ 0
  アクセス権はファイルは666から、ディレクトリは777からumask値を引いた値
ln でハードリンク、ln -s でシンボリックリンク作成
ps, pstree, pgrep でプロセス参照、top でシステム状況を一定間隔で表示
kill, killall, pkull でプロセス終了・再起動等
1:HUPハングアップ、2:INT割り込みctl+c、9:KILL強制終了、15:TERM終了デフォ、18:CONT再開、19:STOP一時停止
コマンドラインの最後に&でバックグラウンド実行
jobs でシステム上のジョブを確認
ログアウトでもプログラムを実行しつけるには nohup
 nohup python main.py &
 ログアウトしてもバックグラウンド ジョブを継続する方法 (codereading.com)
free でメモリの利用状況を確認
uptime でシステムの平均負荷を確認
nice でプロセスの実行優先度を指定、変更には renice
ナイス値-20-19で実行優先度を指定

■デバイスとLinuxファイルシステム
fdisk, gdisk, parted でパーティション作成
mkfs でファイルシステムを作成
ext2, ext3, ext4ファイルシステムを作成するには mke2fs
mkswap でスワップ領域を作成
df でファイルシステムの利用状況を確認
du でファイルやディレクトリを含めたサイズを確認
fsck, e2fsck でファイルシステムの整合性チェックや修復
ext2, ext3, ext4ファイルシステムのパラメータ設定は tune2fs
mount でファイルシステムのマウント、解除は umount
継続利用や頻繁利用のファイルシステム情報は /etc/fstab に格納
ディスク利用容量の制限はディスククォータを使う、ハードリミット、ソフトリミット、猶予期間を設定できる
find, locate でファイル検索、locateはあらかじめ準備されたDBに基づいて検索
which, whereis でコマンドのフルパスを表示

■シェル、スクリプト、データ管理
コマンドの別名設定は alias、設定解除は unalias
関数の定義はfunction、定義済み関数を表示は declare -f
bashのログイン時に全ユーザで実行される/etc/profile、ユーザ毎は~/.bashrc
条件判定するには test
直前に実行したcmdの戻り値は$?で確認できる、正常終了:0、それ以外はそれ以外の値が多い
条件分岐 if-then-else-fi、case-in-esac
繰り返し for-in-do-done、while-do-done
seq は連続した数値を生成する
read は標準入力から文字列を読み込んで変数に代入する

■ユーザインターフェイスとデスクトップ
Xサーバは入出力管理を担当、Xクライアントはユーザアプリに対応
Xの設定はxorg.confでセクションごとに記述する、セクション:
 ServerLayout=入出力デバイスとスクリーン
 Files=フォントやカラーDBファイルのパス
 InputDevices=キーボードやマウスなど入力装置の設定
 Monitor=モニター設定
 Device=ビデオカードの設定
 Screen=ディスプレイの色深度や画面サイズ設定
Xサーバとクライアントが別コンピュータの場合の設定
 1)Xクライアントで環境変数DISPLAYにXサーバを指定
 2)XサーバでXクライアントからのアクセスを受け付けるよう xhost で設定
xwininfo はウィンドウの情報を表示する
ディスプレイmgrはユーザ認証やシェルの起動で XDM, GDM, KDM, LightDM等
ウィンドウmgrはXの外観で twm, fvwm, enlightenment, Mutter, Fluxbox, Compiz, KWin等
キーボードのアクセシビリティには スティッキーキー、スローキー、バウンスキー、トグルキー、マウスキー等

■システム管理1
ユーザ情報は /etc/passwd に格納
シャドウパスワード利用時はパスワード情報は /etc/shadow に格納
グループ情報は /etc/group に格納
ユーザ情報の追加 useradd
ユーザ情報の削除 userdel
ユーザ情報の変更 usermod
グループ情報の追加 groupadd
グループ情報の削除 groupdel
グループ情報の変更 groupmod
ユーザパスワードの設定 passwd
useradd時は /etc/skel以下がユーザのホームdirにコピーされる
定期的なジョブ実行には cron
cronへのジョブ追加は crontab 分時日月曜日cmdの記述順
 ユーザーを指定してcronを実行 | Codebase Blog
 ログインユーザで設定・実行される(sudo crontab -eでRoot実行という意味)
システムが起動していなかった時のcronジョブは anacron で実行
anacron の設定は /etc/anacrontab
1回限りのジョブ予約は at 日時cmd、確認は atq あるいは at -l
ジョブの削除は atrm あるいは at -d
ロケール確認は locale
文字コードを変換 iconv
タイムゾーンは /usr/share/zoneinfo 以下にあり /etc/localtime にコピーする
システムのタイムゾーンは環境変数 TZ、/etc/timezone に設定する

■システム管理2
システムクロックを設定するには date
ハードウェアクロックは hwclock
NTPサーバに問い合わせシステムクロックを設定するには ntpdate
NTPサーバプロセスは ntpd、設定ファイルはntp.conf
syslogの設定は etc/syslog.conf、ファシリティ、プライオリティに応じたログの出力先を指定
rsyslogの設定は /etc/rsyslog.conf
logger でログの生成ができる
ログローテーションは logrotate、設定は /etc/logrotate.conf
メールサーバMTAには Postfix, sendmail. qmail, exim等
メールアドレスの別名は /etc/aliases で定義し newaliases で有効にする
メールの転送は ~/.forward で設定する
メールキューの状況は mailq で確認
印刷は lpr で行う、 -# オプションで印刷部数
プリントキューの状況確認は lpq
プリントキューの印刷要求を削除するには lprm

■ネットワークの基礎
IPv4は32ビットで8ビットずつを10進数に変換した表記を使う
IPv6は128ビット
サブネットマスクはネットワーク部とホスト部の境界を表す
IPアドレスとサブネットマスクの論理積がネットワークアドレス
プライベートアドレス クラスAは10.0.0.0~10.255.255.255 (10.0.0.0/8)
クラスBは172.16.0.0~172.31.255.255 (172.16.0.0/12)
クラスCは192.168.0.0~192.168.255.255 (192.168.0.0/16)
サービスとポート番号の対応は /etc/services に記載 Well-Known-Port:0-1023
TCP20:FTP(データ)
TCP21:FTP(制御)
TCP22:SSH
TCP23:Telnet
TCP25:SMTP
UDP53:DNS
UDP67:DHCP(サーバ)
UDP68:DHCP(クライアント)
TCP80:HTTP
TCP110:POP3
TCP123:NTP
TCP443:HTTPS
TCP587:SMTP(サブミッションポート)
IMAP overSSL:993
POP3 overSSL:995
ホストと通信ができるか ping
経由するルータ情報は traceroute や tracepath
ホスト名からIPアドレスは dig や host
ホスト名の確認や設定は hostname
ルーティングテーブルの確認や設定は route
ネットワークインターフェイスの設定や動作状況確認は ifconfig
有効化は ifup、無効化は ifdown
/etc/resolv.conf に参照先DNSサーバを設定する
ホスト名とIPアドレスの対応は /etc/hostsファイルに記述
名前解決の順序は /etc/nsswitch.confに設定

■セキュリティ
スーパーサーバ inted や xinetd は他のサーバプログラムに変わって要求を受けサーバプログラムを起動し常駐プロセスを減らすことでシステムリソースの節約をする
xinetd の全体設定は /etc/xinetd.conf、各サービスの設定は /etc/xinetd.d 以下
TCP wrapper等を利用しているアプリケーションの場合 /etc/hosts.allow や /etc/hosts.denyにアクセス制限を設定する
開いているポートを確認するには netstat, lsof, nmap
パスワードの有効期限を設定するには change
/etc/nologinファイルを作成しておくと一般ユーザはログインできない
su で他のユーザになれる
sudo でroot権限の一部を一般ユーザが利用できる
設定は visudo で /etc/sudoers ファイルに記録される
ユーザが利用できるシステムリソースを設定するには ulimit
OpenSSHはユーザ認証以外にホスト認証も行うセキュアな通信を実現
信頼できるホストのホスト鍵は ~/.ssh/known_hosts
公開鍵認証で利用する鍵ペアは ssh-keygen
scp で安全なファイル転送ができる
ssh-agent と ssh-add でパスフレーズを記憶させることができる
gpg で GnuPGの鍵管理やファイルの暗号化・複合ができる

=============
Level2 Ver4.0
■キャパシティプランニング
メモリやスワップの情報は top, free, vmstat
プロセス情報は top, ps, pstree
CPUの平均負荷(直近1分、5分、15分)は top, uptime
vmstat はメモリや仮想メモリの詳細な状態を継続的に監視
iostat はCPUの利用状況とディスクの入出力の情報を継続的に監視
NFSでは nfsiostat、CIFSでは cifsiostat で
sar で様々なシステム統計情報を確認
w でログイン中ユーザとそのプロセス情報を確認
netstat でネットワークの統計情報を確認
lsof で開いているファイルとポートを確認
システム監視ツールには collectd, Nagios, MRTG, Cacti等でWeb IFあり

■Linuxカーネル
カーネルバージョン確認は uname -r や /proc/version や /usr/src/linux/Makefile
カーネルモジュールは /lb/modules/`uname -r` dirにインスコされる
dirのパスは /usr/src/linux/Makefile で設定
カーネルモジュール操作は:
lsmod ロードされているモジュールをリスト表示
insmod モジュールをロード
rmmod モジュールをアンロード
modprobe 依存関係を解決してモジュールをロード、アンロード
depmod モジュールの依存関係情報を更新
modinfo モジュールの情報を表示
modprobe が利用するモジュールの依存関係情報はmodules.depファイルにあり depmod で更新可
カーネルの設定ファイルは .config
カーネル2.6以降は下記手順でカーネル再構築
make config | menuconfig | xconfig | gconfig
make
make modules_install
make install
初期RAMディスクを作成するには mkinitrd や mknitramfs
デバイスファイルは udev が動的に作成する
udev の設定ファイルは /etc/udev/rules.dディレクトリ以下にある
udevadm monitor で udevd をモニタできる
sysctl でカーネル設定を表示更新できる
dmesg で起動時のカーネルメッセージを確認できる
/proc ディレクトリ以下のファイルを通してカーネルが認識しているハードや実行中のプロセスやシステムリソース等の情報が分かる
/proc 以下の情報は lsdev, lspci, lsusb で表示

■システムの起動
BIOS->MBR->ブートローダ->カーネル->initの順で起動
initの設定は /etc/inittab 、書式は ID:ランレベル:action指示子:処理
ランレベルごとの起動スクリプトは /etc/rc.[0-6].dディレクトリにある
デフォルトで起動するサービスは chkconfig や update-rc.d で設定
起動プロンプトでカーネルやinitに渡すパラメータを指定できる
起動時に指定したパラメータは /proc/cmdline で確認できる
grub でGRUBシェルが使える
GRUB Legacyの設定ファイルは /boot/grub/menu.lst
GRUB 2の設定ファイルは /boot/grub/grub.cfg
GRUB 2の設定は /etc/default/grub に記述し update-grub を実行すると /boot/grub/grub.cfgが生成される
LILOの設定ファイルは /etc/lilo.conf
LILOの設定変更後は lilo よりMBRを更新する
SYSLINUX はFATファイルシステムからカーネルを起動する
ISOLINUXはISO09660ファイルシステムからカーネルを起動する
PXEはネットワークブートの規格

■デバイスとファイルシステム
マウント設定は /etc/fstab で行う、デバイス名にはUUIDやラベルも使える
カーネルがサポートしているファイルシステムは /proc/filesystems で確認できる
/etc/mtab には現在マウントしているファイルシステムの情報がある
/etc/mtab と /proc/mounts はほぼ同じ内容
mount -o remount でファイルシステムを再マウント、マウントオプションの変更に利用
tune2fs で ext2/ext3/ext4ファイルシステムの各種パラメータを表示・変更できる
blkid でデバイスのUUIDを確認できる
sync はディスクバッファ領域にあるデータをディスクに書き込む
mkswap でスワップ領域を作成できる
ファイルとしてスワップ領域を用意するには dd で任意のサイズのファイルを作成する
swapon でスワップ領域を有効化、 swapoff で無効化できる
swapon -s か /proc/swaps でスワップ領域を確認できる
ext2ファイルシステムを作成するには mke2fs あるいは mkfs -t ext2
ext3なら mke2fs -j あるいは mkfs -t ext3
ext4なら mkfs -t ext4
XFSファイルシステムを作成するには mkfs.xfs あるいは mkfs -t sfs
CD/DVD-ROMイメージの作成は mkisofs
ファイルシステムの整合性チェックには fsck あるいは e2fsck あるいは xfs_check
S.M.A.R.T.はハードディスク自己診断機能で smartdデーモンが情報収集する
smartctl で S.M.A.R.T.情報を表示
オートマウントの設定は /etc/auto.master とマップファイルで行う

■高度なストレージ管理
RAID0は冗長性が無いが高速
RAID1は冗長性があるがディスク容量は半減
RAID4やRAID5はパリティを使って冗長性を保つ
RAID4はパリティを専用ディスクに保存、RAID5はパリティ情報を分散
madadm でRAIDを構築・管理
/proc/mdstat でRAIDの状態を確認
物理ボリュームを作成するには pvcreate
ボリュームグループを作成するには vgcreate
論理ボリュームを作成するには lvcreate
スナップショットを利用するとアンマウントなしで lvcreate でバックアップができる
hdparm でIDEハードディスクのパラメータを設定
sdparm でSCSI/SATA/USBハードディスクのパラメータを設定
iSCSIストレージを利用するホストをイニシエータ、iSCSIストレージをターゲットと呼ぶiscsiadm はSCSI管理ユーティリティ
iSCSIストレージ内の論理ドライブ番号をLUNという

■ネットワーク
MACアドレスとIPアドレスの対応はARPキャッシュに保存され、arp で参照・設定できる
ネットワーク関連コマンドでは -n オプションで名前解決を抑制できる
tcpdump はNIC上のパケットをダンプ出力する
GUIのパケットキャプチャツールにはWiresharkがある
netstat はネットワークの情報を表示する
ルーティングテーブルは route で設定する
ip は ipconfig, arp, route といったコマンドと同等の操作ができる
nmap でポートスキャンやIPアドレススキャンができる
NIC間でパケット転送を行うには /proc/sys/net/ipv4/ip_forward の値が1である必要がある

■システムメンテナンス
tarボールは tar を利用して作成・展開する
configureスクリプトはシステム環境に応じたMakefileを生成する、多くのオプションの指定ができる
make はMakefileに記述された処理を行う、Makefileには各種ターゲットを設定できる、ターゲットにはinstall や clean などがある
バックアップには、フルバックアップ、差分バックアップ、増分バックアップなどの種類がある
バックアップなどに利用できるコマンドとして tar, cpio, dd, dump, restore, rsync などがある
mt でテープドライブを操作する
テープドライブを表すデバイスファイル /dev/st0 は巻き戻しあり、/dev/nst0 は巻き戻しなし
ネットワークバックアップツールには Amanda, Bacula, BackupPC などがある
ログイン直後に表示するメッセージは /etc/motd に記述する
ログイン時に表示するメッセージは /etc/issue に記述する
ネットワーク経由のログイン時に表示するメッセージは /etc/issue.net に記述する
バッチを適用するコマンドは patch で -R オプションでパッチの適用と取り消しを行う

■DNS
DNSサーバには、BIND, dnsmasq, djbdns, PowerDNSなどがある
DNSクライアントコマンドには、 dig, host, nslookup がある
BIND9は mdc で管理できる
/etc/named.confでは様々なオプションが指定できる
allow-query DNS問い合わせを受け付けるホスト
allow-recursion 再帰的な問い合わせを受け付けるホスト
allow-transfer ゾーン転送を許可するホスト
blackhole 問い合わせを受け付けないホスト
directory ゾーンファイルを格納するディレクトリ
forwarders 問合せの回送先DNSサーバ
forward forwardersの回送方法
max-cache-size 最大キャッシュサイズ
recursion 再帰的問合せを受け付けるかどうか
version バージョン表示
ソーンファイルのレコードは
SOA ゾーンの管理情報
NS ゾーンを管理するネームサーバ
MX メールサーバ
A ホスト名に対応するIPアドレス正引き
AAA ホスト名に対応するIPv6アドレス正引き
CNAME 別名に対応するホスト名
PTR IPアドレスに対応するホスト名逆引き
SOAレコードのメールは@を.に変更して指定する
ゾーンファイル内では@はゾーン名を表す
MXレコードではプリファレンス値が小さいものほど優先度が高くなる
NSレコードやMXレコードには別名を使わない
BIND9では dnssec-keygen でセキュリティ用のカギを作成できる
dnssec-signzone でゾーンに署名を行う

■Webサーバとプロキシサーバ
Apacheのメイン設定ファイルはhttpd.confだがディストリビューションによって異なる
DirectoryIndexディレクティブでインデックスページを定義する
ErrorDocumentディレクティブでエラーページを定義する
Aliasディレクティブでドキュメントルート外のコンテンツを参照できる
CustomLogディレクティブでログファイルを定義する、デフォルトのログファイルはaccess_logである
ErrorLogディレクティブでエラーログファイルを定義する、デフォルトのログファイルはerror_logである
UserDirディレクティブで公開するユーザのホームディレクトリを定義する
MaxClientsディレクティブで最大子プロセス数を指定する
apachectl でApacheを管理できる
基本認証を使ったアクセス制御でユーザとパスワード設定は htpasswd を使う
ダイジェスト認証を使ったアクセス制御でユーザとパスワードを設定するには htdigest を使う
.htaccessファイルでhttpd.confの設定を上書き、httpd.conf内のAllowOverrideディレクティブで上書きを許可する範囲を設定
AccessFileNameディレクティブで外部設定ファイルの名前を定義する
ApacheではIPベースのバーチャルホストと名前ベースのバーチャルホストを利用できる
SSLサーバ証明書はIPアドレスとドメイン名のペアに対して発行される
NginxはオープンソースのWebサーバ、リバースプロキシサーバである
Nginxの設定は nginx.confを中心とした /etc/nginxディレクトリ以下のファイルで行う
Squidの設定ファイルは squid.confであり、aclディレクティブと http_accessディレクティブでアクセス制御を設定する

■ファイル共有
Sambaユーザを作成するには smbpasswd, pdbedit を使う
パスワード変更には smbpasswd
ユーザ認識方法はsmb.conf のsecurityパラメータで指定
Sambaサーバがマスターブラウザになる優先度はOSレベルに基づく
OSレベルはsmb.confのoslevelパラメータで指定
testparm でsmb.confの構文をチェックできる
smbstatus でSambaに接続されているクライアントとオープンされているファイルを確認できる
nmblookup でNetBIOS名やマスターブラウザを照会できる
smbclient を使うとSambaクライアントとして共有リソースを利用できる
Microsoftネットワークの共有リソースをマウントするには smbmount
rpcinfo でRPCサービスの状況を確認できる
exportfs でエクスポート状況を表示したり/etc/exportsの変更を反映させたりできる
NFSサーバでエクスポートしているディレクトリを調べるには showmount を使う

■ネットワーククライアント管理
/etc/dhcpd.confで割り当てるIPアドレスの範囲を指定するには range 192.168.0.0 192.168.0.99; のように記述する
リース中のIPアドレス情報はdhcpd.leasesファイルに記録される
dhcrelayはDHCPリレーエージェントである
PAMの設定ファイルは/etc/pam.dディレクトリに配置されるが/etc/pam.confが使われることもある
PAM設定ファイルの書式は モジュールタイプ コントロール モジュールのパス 引数
requiredとrequisiteコントロールの違いは認証に失敗したときrequiredは同じタイプのモジュールの実行が全て官僚した時点で認証を拒否するのに対し、requisiteはすぐに認証を拒否する
LDAPエントリはLDIF形式でテキストファイルに記述できる
エントリを一意に識別する名前をDN(識別名)という
個々のエントリはいずれかのオブジェクトクラスに属する
ldapadd でLDAPエントリを追加する
ldapsearch でLDAPエントリを検索する
ldapdelete でLDAPエントリを削除する
ldapmodify でLDAPエントリの内容を変更する
ldappasswd でLDAPエントリに設定されるパスワードを変更できる
OpenLDAPサーバの設定ファイルは slapd.conf
slapadd でLDAPデータベースをリストアできる
slapcat で全てのエントリの情報をLDIF形式で出力できる(オフラインバックアップ)
slapindex でLDAPデータベースのインデックスを再構築できる
SSSDは識別サービス・認証サービスとの通信を管理しキャッシュをするデーモンである

■メールサービス
SMTPサーバには Postfix, exim, sendmailなどがある
メールボックスには1ユーザ1ファイルに格納されるmbox形式と1メール1ファイルに格納されるMaildir形式がある
Postfixのメイン設定ファイルはmain.cfである
postconf で設定パラメータを表示できる
postqueue -p でメールキューを確認できる
postqueue -f でメールキュー内のメール配送を直ちに試みる
/etc/aliases にはメールのエイリアスを設定する。別名指定方法は次の通り
 user[,user..] ユーザのメールに配信
 /path ファイルに追加
 |command コマンドの標準入力へ
 user@domain メールアドレスへ転送
 :include:/path 外部ファイルを読み込む
/etc/aliasesの変更を反映させるには newaliases を実行する
procmail の設定ファイルは/etc/procmailrcと~/.procmailrc
/etc/procmailrcと~/.procmailrcのレシピの書式は次の通り
 :0 [フラグ] [:ロックファイル]
 * 条件式
 アクション
Dovecotの設定は/etc/dovecot.confで行う

■システムセキュリティ
iptables でパケットフィルタリングを設定する
proftpd.confは ProFTPD の設定ファイルである
vsftpd.confは vsftpd の設定ファイルである
pure-ftpd.confは Pure-FTPD の設定ファイルである
/etc/ftpusers にはFTPログインアクセスを許可しないユーザを記述する
信頼できるホストのホスト鍵は ~/.ssh/known_hostsに格納される
公開鍵認証で利用する鍵ペアは ssh-keygen で生成する
~/.ssh/authorized_keysファイルには接続するユーザの公開鍵を登録する
scp で安全なファイル転送ができる
ssh-agent と ssh-add でパスフレーズを記憶させることができる
Snort はネットワークベースのIDSツール
Tripwireはファイルの改ざんを検知するIDSツール
OpenVASは脆弱性のチェックを行うツール
Fail2banはログから判断して攻撃を遮断するツール
nmap はポートスキャンを行うツール
開いているポートは netstat, lsof, nmap, fuser などのコマンドで調査
OpenVPNにはルーティング接続とブリッジ接続がある
OpenVPNサーバにはCA証明書、サーバ証明書、サーバ秘密鍵、DHパラメータを配置する
OpenVPNクライアントにはCA証明書、クライアント証明書、クライアント秘密鍵を配置する
OpenVPNサーバはUDPポート1194番を使用する

=============
SELinuxは事後防衛的な手段だ。もしサーバに侵入されたとしても、被害を最小限に抑えるための仕組みとなっている。そのため侵入事態を防衛できるものではない
redhat系

この辺は抑えておきたい、昔は無かっただけだと思うが
 LVM(logical volume manager)
 シェル変数をexportして環境変数
 ルートログイン不可、警告文表示
 プロセスの優先順位ナイス値
 バックグラウンドジョブでログアウトしても実行
 スーパーサーバ、TCPwrapperでプロセス省略
 パケットフィルタリング、ルーティングテーブル(nat/forward)
 SSHポート転送(popやftpでも可)

ver5でもそれほど変化がないのでは、systemdの強化辺りか?gitやdockerをカバーしたように思ったが?

=============
/etc
 各種の設定ファイルの保存場所 hostsとか.confとか
 バイナリファイルを置かないこと
 /opt用の設定ファイルを置くために/etc/optを設けること
/opt
 アプリパッケージ
/usr
 各ユーザー共通利用のプログラムやライブラリが置かれるunix shared resouces
/var
 ログやキャッシュ、再起動しても残り続ける
 /etc/logrotate.confで1週間4世代等を設定
/sbin
 システム管理者用bin

/etc/fstab マウント情報が記載されている
mount -a マウント情報を書き直すと全てマウントしなおす

■/varを別ディスクにしたい
デバイスを追加しフォーマット
fstabにマウントとディレクトリの紐づけを追記(新ディスクと/var)
マウントやリブート前に既存ファイルの移動対処
 tmpDirを作成
 mount (type) (device) (mountDir:tmpDir)
 cp -a 旧 tmpDir
リブート

Posted by funa : 03:20 AM | Web | Comment (0) | Trackback (0)


April 23, 2022

Goo ana 4
Google Analytics 4 ガイド – アクセス解析ツール「Google Analytics 4」の実装・設定・活用のための情報サイト (ga4.guide)
GA4代替のアクセス解析ツール候補、あるいはユーザーのデータをどこに預けるべきか - makitani.com
トップページ - GA4 Quick.com (and-aaa.com)

Xゲーム千葉見に行ったが、時間の都合上すぐ引き上げた。なお練習走行をゲート隙間から見れたが、ババババとレブしてる爆音とともに、ヘルメットだけが左右にスー―っと移動しているのだけが見えた。ヘルメットだけが移動する様はシュールだなと思た。オワリ



■なんかやってくれる系のWebサービス
Bard へようこそ (google.com)
Microsoft Bing の Image Creator
パープレキシティ
Bing
Chat GPT(文章生成)
誰でもブラウザで簡単にAI作曲。AIボーカルも入って1日5曲まで無料で作れるSongR BETA登場 | DTM (dtmstation.com)
Jasper(文章生成)
quillbot ai(文章生成)
StoryLab(文章生成)
Tweet Hunter(SNSコンテンツ作成)
Repurpose IO(SNSマルチ投稿)
Timely(ビジネス)
fireflies
Dream by WOMBO(画像生成)
removebg(背景削除)
petalica paint(絵を着色)
YouTube Summary with ChatGPT Chromeの拡張機能でYoutubeの音声を一瞬で文字起こし
ChatGPT内蔵の海外激ヤバサービスまとめ10選!! | 株式会社SaaSis

ASCII.jp:画像生成AI「Midjourney」の始め方・使い方 (1/3)
ASCII.jp:画像生成AI「Midjourney」でLINEスタンプを作ろう (1/3)
画像生成AI「Midjourney」の勘違いによる出力結果
ドラッグするだけで自由自在に画像編集できるAIツール「DragGAN」
雑コラをAIでリアルにする!|Katsushiro Koizumi (note.com)

■GPTプロンプト
ChatGPTに組織の価値観を読み込ませて、マネージャの代わりに論点出しさせる (newspicks.com)
ChatGPTに要件定義をお願いしたらハンパなかった | DevelopersIO (classmethod.jp)
Chat GPTの完全な上位互換!Bing AIの面白い使い方まとめ|梶谷健人 / Kent Kajitani|note
「ビジネスメールでも送信ボタンを押すだけ」情報伝達部分ってそんなにない
深津さん考案「深津式汎用プロンプト」でChatGPTが劇的に使いやすく
ChatGPTをより有効的に使う為のテンプレートがまるで呪文「検索エンジンでキーワードを捏ねるのと似てる」
新しい清涼飲料水の商品企画の例
ChatGPTをRHELの運用に使えるか? いろいろためしてみた。 - 赤帽エンジニアブログ (hatenablog.com)
婚活アプリでChatGPTに代筆させてる話 (hatelabo.jp)
コピペOK!ChatGPT×英語学習に使える「深津式プロンプト」 (thepast.jp)
ChatGPTに感情回路を埋め込んだら、やべぇ感じになった|深津 貴之 (fladdict)|note
 エヴァのMAGIシステムをGPT3で作ってみた|深津 貴之 (fladdict)|note
VSCodeにChatGPTの拡張機能を入れてコードレビューやバグを発見してもらう - Qiita
Chat GPT暗記ツール。覚えらない単語30個指定して「ショートストーリーを作って」
GPT-3 API を使って AI WAF を作る - まったり技術ブログ (motikan2010.com)
シェルコマンド思い出せないので、ChatGPTで自然言語からスクリプトを生成するツールつくった
AIにコードまるごと解説してもらうと、界王拳100倍すぎる件
雑なプロンプトでも勝手に高品質になる
ChatGPTで競合調査やKPIの設定をやってみよう【海外記事メモ】|やました|note
ChatGPTにマインドマップを作ってもらったら理解速度が爆速になる件|Abiru|note
Swift未経験の医師が、ChatGPTを使って30分でiOSアプリを作った話|Shohei|note
【ChatGPT】個人的お気に入りプロンプトまとめ (zenn.dev)
【ChatGPT】これだけ覚えればOK?ゴールシークプロンプトが誰でも使えて最強すぎた|Masaki KANAI|note
AIに「お前のところの営業担当、マジでクソだ、二度と顔見せんな。替えろ」をメールの文章に変換してもらったら超実用的だった - Togetter
ChatGPTで無料で学べる『英会話AI』の作り方(神田敏晶) - 個人 - Yahoo!ニュース
ChatGPTを使ってDDLからER図をすばやく作成する - Taste of Tech Topics (hatenablog.com)
いいよ↓
話題の「ChatGPT」こんなに使えたら本当にすごい! 目からウロコの使い方を解説|GPTs活用事例も | 【レポート】Web担当者Forumミーティング 2023 秋 | Web担当者Forum (impress.co.jp)

【Google Bard】伝説が始まりそうなヤバい使い方10選 | 株式会社SaaSis

■GPT系API利用
ChatGPT APIを使ったLineBotの作り方、人格の与え方まで
ChatGPTを使って自分のはてなブログとチャットするツールを作った - $shibayu36->blog;

■ChatGPTのハルシネーション
ChatGPTはクエリに最も一致すると思われる単語の文字列を予測することで機能する
これはロジックを検討したり、 吐き出している事実の矛盾を考慮したりする理由がない
知らない、分かりませんとChatGPTは言わないことになる→幻覚を出してくる

避け方
 自由記述式より多肢選択式。できるだけ情報を与える
 ロールを割り当てると、より多くのガイダンスが与えられることになるので良い
 欲しいものと欲しくないものを伝える
 AI温度設定を高るとランダム性が高くなり創造的な幻覚的な返答の可能性が高まる

駄目なプロンプト「生産性について書いてください」
適切なプロンプト「中小企業にとっての生産性の重要性についてブログ記事を書いてください」
駄目なプロンプト「犬のハウス トレーニング方法について書いてください」 
適切なプロンプト「プロのドッグトレーナーとして、3か月の新しいコーギーを飼っているクライアントに、 子大のハウス トレーニングに必要な活動についてメールを書いてください」
駄目なプロンプト「落ち葉についての詩を書いてください」
適切なプロンプト「落ち葉について、エドガーアランポーのスタイルで詩を書いてください」
駄目なプロンプト「この記事を書約してください」
適切なプロンプト「この記事の要約を500語で書いてください」
適切なプロンプト「例)
入力: 2023-04-02 T16:10:00Z
3 日を追加し、次のタイムスタンプをMM/DD/YYYY HH:MM:SS形式に変換しますと下記になります。
出力:  04/05/2023 16:10:00
下記の入力に3 日を追加し、次のタイムスタンプをMM/DD/YYYY HH:MM:SS形式に変換して下さい。 
入力: 2023-03-01 T11:10:00Z」

Posted by funa : 11:00 AM | Web | Comment (0) | Trackback (0)


April 17, 2022

I drive or test driven
Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming.
TDD is dead. Long live testing. (DHH)

I need to hire new techniques to help me solve many of my problems during programming: The pain will fade. Farewell TDD, old friend.
RIP TDD from Kent Beck

そもそもテスト駆動開発の最後のところに、自分で考えてやれって書いてんなぁ、やらんでもええしって。そらそーやろ、自分で考えさせろや、やらんと分からんやろやらせろや、終了ーーーー

==============
となりそうだがドリドリについて
Assertするだけ?、何か一部しかテストでけへんの?
 テストをコード化するのはいい
 テストファーストとテストドリブンとユニットテストは違うらしいで
 javascriptとかテストできんの?

ビジネスをソフトウェアでするだけ
 ソフトウェアを捏ねくりまわしたいのではない
  特にコードをビジネス通りに書くといい
  プログラマー的変換するとよくない、ビジネスはビジネスとしてコード
   ゲームとか処理等の描き切りはスペシャルなコードを書けばいい
  -実現したいことを箇条書きにする
  -プログラムで処理できる内容にまで分解だけする
  -コードにする
 ※実現したいことをそのままコードにする
 ※言語に左右されない粒度、機能でシンプルに簡易な書き方だけにする

脳に収まっとんのか?と。
大事なのはこっちだろ。
 -コミュニケーション
 -組織力
 -リサーチ
 -実行
※企画/予算/収支、UX/デザインの決定

他人が使うソフトウェアなら必要、自分も使うソフトウェアなら不要では
 自分でも使うくらい有用なものであるか
 品質をどこで担保するか、機能だけなのかUXなのか
 スーパープログラマには本質の部分にもっと時間を使って欲しい、死ぬ方が早い
 あんまり機能をリファクターする機会がないかも

++++++++++
ソフトウェア開発
アプリケーションを超シンプルにするとリリース回数が多くなる(質とスピードを上げるにはリリース回数)
アプリの分散と並列も可、競争力はオリジナリティ、政治力か真理性か
原体験、初期衝動は、グラスルーツかグルーピーか

==============

変な常識ばかり、旧来のITがWeb業に飲み込まれ使えるようになったが、ITvsWebの何がエッセンスだったかCSは与り知らん
新しい(変化する)事は良いことみたいな感じでやってきたところもあるが、今時変化っつーたら怪しいわな。不要な変化を押し付けられたり、本当に変えるべきところを隠すために変化してたり。コンサバでええかもな

==============

リーダブルコードの要点整理と活用法をまとめた - Qiita
これはいいな
「良いコード」を書くために意識している17のTips まとめ (zenn.dev)
これも
すべての新米フロントエンドエンジニアに読んでほしい50の資料 - Qiita
知らん事結構ある、keep them simpleだが知っておかんとな、下とか
オリジン間リソース共有 (CORS) - HTTP | MDN (mozilla.org)
JSON Web Token(JWT)の紹介とYahoo! JAPANにおけるJWTの活用 - Yahoo! JAPAN Tech Blog
Overview - Chrome Developers


Posted by funa : 09:54 AM | Web | Comment (0) | Trackback (0)


April 1, 2022

GCP Python script
Googleがサポートするのは3つ
 pip install google-cloud-dialogflow
 GCPは下記のRESTがベースにあるらしいがコレが楽かと
2)REST https://googleapis.github.io/HowToREST
 URLにAuthベアラーと必要ならJSONを投げてJSONを受け取る
 URLに法則性があり get とか list
 なぜかうまく行かないことが多い
3)gRPC https://grpc.io/

■サンプルコードのライブラリを検索するとAPIドキュメントは引っかかる
APIドキュメント
APIはgithubにコード公開されている
親分はGoogle APIs on guthub

■python gcp Cloud API client libraryは下記のような所からサンプル、仕様を取る
client(bq)
pip install google-cloud-resource-manager
pip install google-cloud-biguery-datatransfer

#Pyton Bigquery
requirements.txt
google-cloud-bigquery==3.3.2
google-cloud-logging==3.2.2
----
from google.cloud import bigquery
import google.cloud.logging
import logging
bq = bigquery.Client()
sql = "select * from `unco`"
results = bq.query(sql)
row_counts = 0
for row in results:
bq_insert = bigquery.Client()
sql_insert = "insert into `benki` (a) values ('" + str(row.size) + "')"
logging.warning('### unco.size ' + str(row.size) + ' ###')
row_count += 1

#Python pubsubデータ取得(pubsub pushの場合)
requirements.txt
google-cloud-logging==3.2.2
----
import base64
import json
import google.cloud.logging
import logging
pubsub_data = base64.b64decode(event["data"]).decode("utf-8")
logging.warning('### pubsub data ' + str(pubsub_data) + ' ###')
json_pubsub_data = json.loads(pubsub_data)

#Python slack送信
requirements.txt
google-cloud-secret-manager==2.12.6
----
import requests
from google.cloud import secretmanager
import json
def slack_post(message):
client = secretmanager.SecretManagerServiceClient()
resource = "projects/12345678901/secrets/secretkey_xxx/versions/latest"
res = client.access_secret_version(name=resource)
slack_url = res.payload.data.decode("utf-8")
payload = {
"text": message,
}
notify = requests.post(slack_url,data=json.dumps(payload))
if notify.status_code != requests.codes.ok:
print("error")
else:
print("posted at slack url")
slack_post('続きは<http://yahoo.com| こちら>をクリックしてください)

@ .dockerignore
Dockerfile
README.md
*.pyc
*.pyo
*.pyd
__Pycache__
.pytest_cache

@ Dockerfile
FROM python:3.10-slim
ENV PYTHONUNBUFFERED True
ENV APP_HOME /app
WORKDIR $APP_HOME
COPY . ./
RUN pip install --no-cache-dir -r requirements.txt
RUN pip install Flask gunicorn
CMD exec gunicorn --bind :$PORT --workers 1 --threads 8 --timeout 0 main:app

@ Dockerfile
FROM python:3.10-slim
WORKDIR /app
COPY app /app
RUN pip install -r requirements.txt --proxy=http://proxy:3128
CMD["python", "main.py"]

■Slack通知
incoming webhookかSlack apiの最低2種類がある
Slack apiではts(timestamp)が取得できスレッド返信ができるが、incomingは投稿だけ。incomingは管理画面でURLを取得しそこへPostすることで投稿ができる(URLのみで漏洩すると誰でも投稿できる、どのSlackアプリが投稿しているか分かるのでURLローテすれば良いが)。
apiはSlack固定のエンドポイントがありトークンをベアラに入れチャネル名を指定して投稿ができる。管理画面でトークン取得と権限スコープの設定をし、チャネル側でapiアプリの受け入れをintegrations設定する
URLあるいはトークンをGCPシクレMGRに入れて、アプリで読みEPへhttp通信する
APIのテスト送信ができる

■Oauth関連
ローカルの場合(VirtualBoxとか)
 1) gcloudでログインをしてPython実行する
OauthクライアントIDの場合
 2) ローカルPythonを実行するとAuthを聞いてくる>ブラウザが立ち上がる>ユーザ認証に変わる
 3) WebアプリだとJSでAuthを聞く> 認証するとOauthクライアントIDでなくユーザ認証に変わる
設定方法
 OauthクライアントIDをOauth同意画面>クレデンシャルで作成
 デスクトップアプリは上記②、Webアプリは上記の③でID作成する
 OauthクライアントIDをファイルかsecret mgrに入れてOauth認証通信をさせる
  ②flow = InstalledAppFlow.from_client_secrets_file(credentials, SCOPES) 
  ③flow = InstalledAppFlow.from_client_config(json.loads(credentials), SCOPES)
サービスアカウントの場合
 4) Cloud run等のサーバがOauth通信で認証し外部サービスを使う
設定方法
 SAキーをファイルかsecret mgrに入れてプログラムからOauthで認証させ外部サービスを使う
  EPはホスト名+パスだが、target_audienceはホスト名

GCPのOauthについて
https://www.marketechlabo.com/python-google-auth/

Docs API
https://developers.google.com/docs/api/how-tos/documents?hl=ja#python
https://rimever.hatenablog.com/entry/2019/10/16/060000
スコープ
https://developers.google.com/identity/protocols/oauth2/scopes?hl=ja#docs
google-api-python-client OAuth 2.0
https://googleapis.github.io/google-api-python-client/docs/oauth.html
Oauthライブラリ
https://google-auth.readthedocs.io/en/stable/reference/google.oauth2.credentials.html
https://google-auth-oauthlib.readthedocs.io/en/latest/reference/google_auth_oauthlib.flow.html
https://googleapis.dev/python/google-auth-oauthlib/latest/reference/google_auth_oauthlib.helpers.html
https://google-auth-oauthlib.readthedocs.io/en/latest/_modules/google_auth_oauthlib/flow.html#Flow.from_client_config 
Oathライブラリのソースコード
https://github.com/googleapis/google-auth-library-python-oauthlib/blob/main/google_auth_oauthlib/helpers.py
OauthクライアントIDの仕様
https://github.com/googleapis/google-api-python-client/blob/main/docs/client-secrets.md
サービスアカウントで外部サービスのAPIを使う
https://www.coppla-note.net/posts/tutorial/google-calendar-api/
SAのサービス間認証の仕様
https://cloud.google.com/run/docs/authenticating/service-to-service?hl=ja#use_the_authentication_libraries
WebアプリのOauth認証
https://github.com/googleworkspace/python-samples/blob/main/drive/driveapp/main.py
https://stackoverflow.com/questions/10271110/python-oauth2-login-with-google

■Oauthについて
下記の少なくとも下記の種類があり、クライアントライブラリやコード等々で違いで使い分ける必要がある。今回はSA+シクレmgrを使用した。
-ローカル(gcloud auth login と認証)
-OauthクライアントID (アプリ上で認証が個人ユーザに引き継がれる)
 -デスクトップ
 -Webアプリ(jsでサイト上)
-サービスアカウント
 -キーファイル
 -シクレmgr

使用ライブラリーに注意
1) OauthクライアントID (ローカルファイル)
from google_auth_oauthlib flow import InstalledAppFlow
flow = InstalledAppFlow.from_client_secrets_file("credentials.json", SCOPES)
creds flow.run_local_server(port=0)

2) ローカルにおいたSAキー
from google auth import load_credentials_from_file
creds = load_credentials_from_file('credentials.json', SCOPES)[0]

3) Secret mgrにおいたSAキー
import json
from google.oauth2.service_account import Credentials
from google.cloud import secretmanager
client = secretmanager.SecretManagerServiceClient()
resource_name = "projects/()/secrets/{}/versions/latest" format(project_num, secret_name)
res = client.access_secret_version(name=resource_name)
credentials = res.payload.data.decode("utf-8")
cred_dict=json.loads(credentials)
creds = Credentials.from_service_account_info(cred_dict, scopes=SCOPES)
creds.refresh(Request())

※) これは使わない
from google.oauth2.service_account import IDTokenCredentials
#ファイルから
credentials = IDTokenCredentials.from_service_account_file(service_account,target_audience=target_audience)
#シクレmgrから
credentials = IDTokenCredentials.from_service_account_info(service_account.target_audience=target_audience)

ライブラリーのソースコード本体や仕様書
https://github.com/googleapis/google-auth-library-python-oauthlib/blob/main/google_auth_oauthlib/helpers.py
https://googleapis.dev/python/google-auth-oauthlib/latest/reference/google_auth_oauthlib.helpers.html
https://google-auth-oauthlib.readthedocs.io/en/latest/reference/google_auth_oauthlib.flow.html
https://google-auth-oauthlib.readthedocs.io/en/latest/_modules/google_auth_oauthlib/flow.html#Flow.from_client_config

サービスアカウントのライブラリ情報
https://google-auth.readthedocs.io/en/master/reference/google.auth.html
https://google-auth.readthedocs.io/en/master/reference/google.oauth2.service_account.html#module-google.oauth2.service_account
https://qiita.com/que9/items/38ff57831ea0e435b517


Posted by funa : 12:00 AM | Web | Comment (0) | Trackback (0)


March 30, 2022

GCP runs off functions pubsub on scheduler
run:言語自由、リクエストタイム60分
functions:リクエスト9分、関数をデプロイ
  gke auto pilot mode:制限がなくなる
Cloud Run で作るサーバーレス アーキテクチャ 23 連発 - これのときはこう! (zenn.dev)

■RUN
httpリクエストでコンテナを呼び出す
Google Cloud Run を使うまで - Qiita

■ハンズオン(run)
クイックスタート: ビルドとデプロイ  |  Cloud Run のドキュメント  |  Google Cloud
クイックスタート: Cloud Run に Python サービスをデプロイする  |  Cloud Run のドキュメント  |  Google Cloud
基本はFlaskのhttp responseを返すコードである必要があるみたいだ
 Scheduler手動 > Pubsub > Eventarc > Cloud runのでキックで実行がいい
ローカルやterminalなどで作成しcmdでレジストリに入れるが、~/unco で下記作成
 Dockerfile
 .dockerignore
 main.py
コンテナイメージにパッケージ化しContainer Registry にアップロード
 gcloud auth application-default login
 gcloud run deploy (対話型でデプロイまでできるが、SAはデフォルトになる)
 gcloud builds submit --tag gcr.io/bangboo-run/unco (ビルドのみ、手動でコンソールでSAを指定しデプロイする)
  gcloud builds submit --pack image=gcr.io/bangboo-run/unco ならDockerfile不要らしい
コンソールでデプロイ(trigger/permission)-新ver更新のときTagを付けなおす?
 設定allow all traficとAllow unauthenticated invocations、権限allUsersにCloud Run Invokerではブラウザでも上手行く
 設定allow all traficとrequire auth(IAM)、権限allAuthenticatedUsersにCloud Run Invokerのとき
  IAMが要るのでターミナルから
  curl https://unco-zp2aehj5rq-an.a.run.app/ ではIAM要求の場合は駄目
  curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" https://unco-zp2aehj5rq-an.a.run.app/ で上手行く
 設定allow internal traffic onlyとrequire auth(IAM)、権限allAuthenticatedUsersにCloud Run Invokerのとき
  ターミナルはinternal trafficでないから
  curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" https://unco-zp2aehj5rq-an.a.run.app/ でも駄目
インターナルでIAMを使うにはどうする?(同セグメントvpcからcurl bearer、vpc scかpubsubかEventarcだけ、terminalやschdulerは駄目)
 →IAMを使うならallow all traficでいいのでは、allusersにinvokerを付与しなければいいし
 →怖ければ同セグメントにVMを立ててそこからキック、あるいはScheduler手動 > Pubsub > Eventarc > Cloud runがいい
runのデフォルトのSAは別のrunでも同じSA実行として使い回されるので、別途作成したものを指定したい
 デプロイをコンソールで実行するとサービスアカウントを指定できる(runのPermissonでそのSAにinvokerを付ける)
ブラウザ+IAMをrunで使うにはIAP
 global ip、ドメイン、DNS、証明書、設定allow all traficとrequire auth(IAM)、権限各メールidにinvoker
LBはバックエンドにserverless network end groupを選べばいい

/// IAP
(古い方法)
IAPを使う場合はトリガーをAllow unauthenticated invocationsにする
 現行だけだそうだが、IAPに全委任するために必要となっている
 つまりIAPはLBが必要なため、Allow internal taraffic and from cloud load balancingとのコンビでトリガー設定をする
権限はCloud runのallusersが付き個別のinvokerは不要となり、必要なものはIAP上で付与をする
 IAP上のWeb app userに Allautheticatedusersを入れると、識別できる誰でも入れてしまう
 アクセスを許可したいユーザのみ個別でweb app userをIAPで付与すること
IAP で保護されたリソースへのアクセスの管理  |  Identity-Aware Proxy  |  Google Cloud

(新しい方法)
特定のユーザだけCloudRunを利用させてたいなら:
 (run)認証ユーザ+(run)内部トラフィックとLB経由+IAPのwebuserの設定
 Cloud runでIAPを使用するIAP用隠れSAの権限:
  プリンシパル: service-[PROJECT-NUMBER]@gcp-sa-iap.iam.gserviceaccount.com
  ロール: Cloud Run invoker
AllUsersでなく、上記のIAP用隠れSAに権限を振ればIAPがrunを起動する
 利用ユーザはIAPでwebuserの権限を与える

===
dockerfileに記載
FROM google/cloud-sdk:latest
 PythonモジュールでなくOS側にインストールする必要がありコンテナ化のDockerfileに記載できる
 /// BANGBOO BLOG /// - k8s にDocker記載がある
FROM python:3.9-slim
ENV PYTHONUNBUFFERED True
ENV APP_HOME /app
WORKDIR $APP_HOME
COPY . ./
#RUN pip install --no-cache-dir -r requirements.txt
RUN pip install Flask gunicorn
CMD exec gunicorn --bind :$PORT --workers 1 --threads 8 --timeout 0 main:app

 python requirements.txtでは google-cloud-bigqueryはインスコできるがsdkは無理
  main.pyに from google.cloud import bigquery
  Dockerfileでイメージでgoogle-cloud-sdkが入ればPythonのsubprocessでgcloud cmdが打てる
  Dockerのベースイメージを FROM google/cloud-sdk:latest にして
   RUN apt-get update && apt-get install -y \
    python3-pip
   RUN pip install --no-chache-dir -r requirements.txt
  Cloud API client library for pythonを使うにはrequirements.txtに
   google-api-python-client

Dockerfileの動作はCloud buildのhistoryで見れる
RUN which gcloud
RUN echo $PATH

OSの実行ユーザとコンテナ内のユーザを合わせないとファイル読み込み等ができない
 permission deniedになる
 Cloud runのそれぞれのユーザが誰なのか分からない(上記でわかるが)
 Dockerfileに RUN chmod -R 777 /app と入れてしまう

===
Cloud Run のトリガーを作成する  |  Eventarc  |  Google Cloud
runとscheduler/pubsubの連携は eventarc triggerの設定が良さそう
これはAudit logに既定のものが記載されると発火されるというもの
 設定したrunのサービスのトリガー項目に
  google.cloud.scheduler.v1.CloudScheduler.Run.Jobを設定(スケジューラ手動実行ならこれでも連携する)
  google.cloud.pubsub.topic.v1.messagePublishedを設定 (Pubsub経由のEventArcなら)
 色んなAPI有効が必要 クイックスタート: Pub/Sub メッセージを使用してイベントを受信する(Google Cloud CLI)  |  Eventarc
Schedulerとの連携に使う場合、手動実行でAudit logに記載され動くが、cron定期実行ならAudit logがなく動作しない事が分かった
 internal trafficなら Scheduler > Pubsub > Eventarc > Cloud run

■Scheduler
 get で https://run-service-name-.kuso.run.app
 0 7 * * 1 毎週月曜の6時
 Auth headerに add OIDC token
 runのサービスにinvokerを付けたSAを指定
 5回リトライ/最大リトライ0sで制限なし/バックオフ最小180s最大1h/期間倍5回
  サービスアカウントにCloud service agentロールが必要

===
■Run jobs
runはジョブならFlask不要で簡易。だがEventarc-Schedule連携がまだGAでなくできないので単発手動実行用。

Procfile作成
web: python3 main.py

pipしたいものは requirements.txtに書く
 バージョンは google-cloud-bigquery · PyPIで調べる
google-cloud-bigquery==3.3.2

main.py作成
コードを書く from google.cloud import bigquery

gcloud auth application-default login
 run job実行とコンテナのプロジェクトを合わすなら
 gcloud config set project bangboo-runs
 下記は通常不要なようだ
 gcloud auth configure-docker

Buildpackを使用してコンテナをビルド
 Cloud buildデフォルトサービスアカウントにGCSバケット権限必要 123456@cloudbuild.gserviceaccount.com
gcloud builds submit --pack image=gcr.io/bangboo-runs/run_data_to_bq
 bangboo-runsのコンテナレジストリにrun_data_to_bqができている

Cloud runでジョブを作成
gcloud beta run jobs create job-run-data-to-bq \
    --image gcr.io/bangboo-runs/run_data_to_bq \
    --task 1 \
    --set-env-vars SLEEP_MS=10000 \
    --set-env-vars FAIL_RATE=0.5 \
    --max-retries 0 \
    --region asia-northeast1
(gcloud beta run jobs create --helpで見るとenv-varのハンドルは何もないのでコードでエラースローする必要がありそう、そこでスリープとか使ってエラーを吐くと、リトライはしてくれそう。taskを複数にすると同時に何個も動く)

ローカルでテスト
docker run --rm -e FAIL_RATE=0.9 -e SLEEP_MS=1000 gcr.io/bangboo-runs/run_data_to_bq

Cloud runでジョブを実行
gcloud beta run jobs execute job-run-data-to-bq

============
from flask import Flask #モジュール読み込み
app = Flask(__name__) #Webアプリ作成
@app.route("/", methods=["GET","POST"]) #エンドポイント設定(ルーティング)
def index():
if __name__ == '__main__': #Webアプリ起動
  app.run(debug=True)

request.form.get('name', None) 第2引数にデフォルト値入れられるらしい

■Flask LBでパスを分ける場合
LB
 sub.domain.com /* backend-1
 sub.domain.com /dir/* backend-2
Flask
 @app.route("/dir/index", methods=["GET","POST"])
 ドメインがこの場合:https://sub.domain.com/dir/index
 Flaskには元のルートパスから指定する
●外部ファイルのstaticフォルダはカスタムルートが必要
 Flaskルートの指定になるので/static/等になりLBで振り分けた場合は都合が悪い
 Cloud runルートからの指定として/dir/static/style.css等にするにはカスタムルートが必要
Python flask
 from flask import Flask, send_from_directory
 @app.route('/dir/static/<path:filename>')
 def custom_static(filename):
  return send_from_directory('static', filename)
Python flask html
 <link rel="stylesheet" href="{{ url_for('custom_static', filename='style.css') }}">
 トップレベルにstaticフォルダを作り静的ファイルを入れる
ブラウザ表示
 <link rel="stylesheet" type="text/css" href="/dir/static/style index.css">

■Flask jinja2
{# comment #} テンプレートのコメント
Template Designer Documentation — Jinja Documentation (3.1.x) (palletsprojects.com)

============
■functions
コンソールでコード書いてもデプロイエラーになると入力分が消える糞
 テキストで書いてコンソールにペーストしてやった
 開発環境はローカルにすべきだろうな
 【Python】Cloud Functions ローカル環境で開発 デプロイ | のい太ろぐ (noitalog.tokyo)
 Cloud Functionsのローカル開発環境にFunction Frameworkを使用する (rhythm-corp.com)
functionsもhttpで初めに実行される関数はFlaskのflask.Requestオブジェクトを受取る
 PubsubトリガーとかEventarcトリガーもあるようだ
  pubsubトリガーならinetrnal traffic onlyでOKだが、httpsはall traffic必要
requirementsは必要?標準ライブラリならimport文を本体に書いていれば良い
 pprint.pprintでエラー、requirementsの場合PyPIで調べてバージョンも書こう
一時ファイルは/tmpというDIRであるがメモリーに保持される
テストでJSONを書く場合はキッチリ書く(文字はダブルクォート等)
{
"test" : "aaa"
}
functions invoker等のIAMはプロジェクトレベルではなく各functionsに対しての設定が必要そう
functionsのデプロイ時にinternal traffic や allow all trafic等の変更ができる
名前の変更や連携変更はfunctions再作成が必要で面倒

functions では gcloud cmdが打てない、SDKがないから
 クライアントライブラリでは? > 非力そう、、cloud runならSDKでDockerしgcloud cmd打てる
 Cloud クライアント ライブラリ  |  Cloud APIs  |  Google Cloud

Functionsはデフォルトで環境変数を持っていてimport os > os.getenv()で取得できる
ENTRY_POINT 実行される関数、GCP_PROJECT 現在のGCPプロジェクトIDとか

■pubsub
GCP - Pub/Sub サービス概要 - Qiita
https://www.bangboo.com/cms/blog/page_378.html
topicという入れ物
 メッセージがpublish投入される(コンソールでも作れるのでinternal trafficのトリガーにできる)
 subscriptionでTopicのデータ取得状況を管理
 subscriptionからsubscribeでメッセージの取得
メッセージは重複する仕様
 Topicにメッセージを入れると勝手に紐づけられたアプリが動く
  フィルターがあり条件を設定をできるがTopicを沢山作ればいいのでは
 サブスクのpullはメールボックスみたいな入るだけ
  functionsのpubsubで作った指定のTopicにメッセージが入れば動く
 サブスクのpushも送信メールボックスみたいで送る
  functionsのhttpで作ったエンドポイントに送られる
 pullは謎に上手く行かなくなる?pushの方が安定かも
  でもトラフィックの種類でpullならinternal traffic OK
   pubsub pull -> functions:pull なら internal traficでもOK
   pubsub push -> functions:push は http なので internal traficダメ
 functionsのデプロイ時にinternal traffic や all等の変更もできる
例えばRunのTriggerでEventarcをPubsubで設定すれば指定のTopicに勝手にサブスクを作ってくれる

pubsubを使うときはrunとかfunctionsとかインスタンス1つの方がいい
 べき等性の構成がなければバッチが勝手にリトライされ同時処理が起こる等で面倒
pubsubのリトライ無しで、returnで何とかhttp200レスポンスを返す
 pythonだとmain()でエラーでもtry-exceptで投げてreturnを返すとhttp200になる
 ackを返す時間デフォ10sであり処理が長いと駄目、-600sと長くするといい

pubsubはbase64ででコードするのにimport base64
pubsubはjsonでデータを持っていてimport json

Posted by funa : 07:59 PM | Web | Comment (0) | Trackback (0)


February 26, 2022

GCP script
GitHub - GoogleCloudPlatform/professional-services: Common solutions and tools developed by Google Cloud's Professional Services team

■gcloud cmd プロジェクト一覧
gcloud projects list --filter="bangboo OR fucu" --format=json
gcloud projects list --filter="bangboo OR fku" --format=json | grep -oP '(?<="name": ")[^"]*'

■pythonでgcloud cmd, 同期処理の方法(run)と非同期処理の方法(Popen)
Pythonからシェルコマンドを実行!subprocessでサブプロセスを実行する方法まとめ | DevelopersIO (classmethod.jp)
--terminalでpython cmd.py python3.7どう?
import json
import subprocess
from subprocess import PIPE
p = subprocess.Popen(cmd , shell=True, stdout=subprocess.PIPE)
out, err = p.communicate()
out = json.loads(out)

[Python2.7] subprocess の使い方まとめ - Qiita
 python2.7やとちょい違うみたい、pipenvでバージョン管理したい?
--terminalでpython cmd.py
import subprocess
from subprocess import call
cmd = 'gcloud projects list --filter=bangboo --format=json'
subprocess.call(cmd, shell=True)

--runでcurl、cmd結果をPIPEで受けたいが
import os
import subprocess
from subprocess import call
from flask import Flask
app = Flask(__name__)
#メソッド省略でGETのみ
@app.route("/", methods=["GET","POST"])
def hello_world():
    name = os.environ.get("NAME", "World")
    cmd = 'gcloud projects list --filter=bangboo --format=json'
    output = ' will die'
    subprocess.call(cmd, shell=True)
    name = "Hello {}!".format(name)
    output = name + output
    return output
if __name__ == "__main__":
    app.run(debug=True, host="0.0.0.0", port=int(os.environ.get("PORT", 8080)))

■pythonでbigquery
from google.cloud import bigquery
client = bigquery.Client()
QUERY = (
    'SELECT name FROM `bigquery-public-data.usa_names.usa_1910_2013` '
    'WHERE state = "TX" '
    'LIMIT 100')
query_job = client.query(QUERY)
rows = query_job.result()
for row in rows:
    print(row.name)

■BigQueryのトランザクション処理
Multi-statement transactions  |  BigQuery  |  Google Cloud
BigQueryはOLAPのため、同時クエリ発行等で、処理時間差や実行順番等で想定と違う場合が多くトランザクション処理は苦手だがコレを使うとよい、例えば、truncateしてinsertするとconcurrentエラーになる場合等
///transactionの注意
複数のSQLをセミコロンで区切った上で連結しBEGIN~END;を一括で発行する必要がある(SQL1行毎発行ではダメ)
BEGINを複数、BEGIN内でTRANSACTIONを複数だとクエリの順番が入れ替わることがあるので注意
 pythontry except else finally(tryはネストOK)とtime.sleepを入れ、挿入して服問い合わせを使い最新以外を削除する妥協策もある
 最新1行だけでなく複数行OKで最新を取得するような構成にして

sql_begin = "BEGIN BEGIN TRANSACTION;"
sql_history = f"INSERT INTO `{ds.tbl}` (record_date. a, b) values (CURRENT_TIMESTAMP(), 'a', 'b');"
sql_commit = "COMMIT TRANSACTION;"
sql_end = "END;"
sql = sql_begin + sql_history + sql_commit + sql_end

■GCPのシークレットマネージャに重要な値を置き、それを取る
from google.cloud import secretmanager
client = secretmanager.SecretManagerServiceClient()
res = client.access_secret_version(resource_id)
value = res.payload.data.decode("utf-8")
GCPのSecret Managerで値を取得しようとしてハマった - Qiita

■GCE(Docker使う版)へSSH後に何をするか
sudo apt-get update

Dockerインスコ

docker --version
who 誰がログインしているか
sudo gpasswd -a [ユーザ名] docker dockerグループへ追加?

■コードをコンテナ化
いったん /home/app_name に置いて
上手く行けば /usr/local/bin/app_name に移動すればいいのでは?
sudo nano 等でファイルを作る

Dockerfileの作成
RUN adduser -D myuser && chown -R myuser /myapp
 (-Dはデフォルト設定で追加している、-Rは指定dir以下を再帰的に所有権変更)
USER myuser
 (以降のRUNやENTRYPOINT等のINSTRUCTIONを実行するユーザを指定)
 (USER nobody ならLINUXユーザで一般ユーザより弱い権限のもの)

Dockerfileをキック、あるいはdocker composeをキック
sudo docker build -t img_unco . でカレントのDockerfileをビルド

docker images リスト
docker tag [イメージID] img_unco:latest 名前がつかない場合
docker rmi [イメージID]  削除
docker ps -a コンテナ一覧
docker rm [コンテナID] 削除

ビルド後にdocker runが必要
docker container run -d --name cnt_unco -v ${pwd}:/app img_unco:latest
↓これが便利
docker container run -rm --name cnt_unco -v ${pwd}:/app img_unco:latest

オプション
-v ${pwd}:/app はOSローカル環境とコンテナ内のディレクトリを同期
-p 80:8000 はポート
-d はバックグラウンド実行(デタッチ)
-rm はrun後にコンテナを自動削除(イメージは残る)

docker compose exec コンテナ名 bash でコンテナに入れる

docker container ls コンテナのステータス確認
GCEはデフォルトサービスアカウントで動作するがgcloudコマンドはgcloud auth loginが必要等々のサービスアカウントのOauth問題等がある(DockerfileのUSERやRUNでgcloud auth default login等で調整する?)

■GCEセットアップ(Docker使わない版)
curl https://sdk.cloud.google.com | bash
gcloud init
直にOSにSDKをインスコしてもdefault service accoutだとVMスコープの問題が出る
 自身のID/SAで権限を付けGCEにログインしgcloud initし操作する
sudo apt update
sudo apt install python3-pip
sudo apt-get install python3
sudo apt install jq
pip3 install --upgrade pip バージョン問題がPythonであるがこれをすると改善する場合あり
pip3 install --upgrade google-api-python-client
pip3 install --upgrade google-cloud-logging
pip3 install google-cloud 要る?
pip3 install google.cloud.bigquery 要る?
pip3 install google.cloud.logging 要る?
 pipでうまくいかない場合 python3 -m pip install google.clud.bigquery と必要ならPythonを通して入れるべき所に入れる
Pythonコードで from google.cloud import logging 等を記載
 import logging も必要(python標準のロギングでlogging.warning()でGCP loggingに書くため)

pipはpythonモジュール用、サブプロセスのOSでコマンドを打つならaptでインスコ
ちなみにrequirements.txtはpip、pip install -r requirements.txt
なお現設定を書き出すには pip freeze > requirements.txt
 pip3 install jq をしていたが不要で sudo apt install jq でやり直した
 pip3 list
  pip3 uninstall jq

gcloud auth application-default login --scopes="https://www.googleapis.com/auth/cloud-platform","https://www.googleapis.com/auth/bigquery","https://www.googleapis.com/auth/drive"
 コマンド打つならgcloud auth loginでログインする(Oauthスコープエラーになるのでスコープも付ける)
python3 main.py で実行

■Google Cloud における認証・認可

Posted by funa : 02:52 AM | Web | Comment (0) | Trackback (0)


December 25, 2021

リンク踏合組合
シンプルで軽量! 新しいCSSリセット「The New CSS Reset」を作成したElad Shechterにインタビュー | コリス (coliss.com)
【2021年版】おすすめのリセットCSSまとめ!基本と使い方の解説も | Web Design Trends (webdesign-trends.net)
【2021年版】リセットCSSのガイドライン|基礎から使い方を徹底解説 - WEBCAMP MEDIA (web-camp.io)

新しい日本語フォントがたくさんリリースされてる! 2021年、日本語の新作フリーフォントのまとめ | コリス (coliss.com)
2022年用、日本語のフリーフォント573種類のまとめ -商用サイトだけでなく紙や同人誌などの利用も明記 | コリス (coliss.com)


BigQueryにおけるポリシータグを用いた秘密情報管理とデータ連携の仕組み - ZOZO TECH BLOG
【新機能】Google Cloud 純正の構成図ツール Architecture Diagramming Tool が発表されました | DevelopersIO (classmethod.jp)
[B! 技術] とりあえずWebサービス作る時の私の技術選定ポイント (hatena.ne.jp)


----------------

LiveとPushを使用した音楽制作 | Ableton
ABLETON LIVE 特集|サウンドハウス (soundhouse.co.jp)
製品情報:APC40:AKAI professsional (akai-pro.jp)

音楽制作に弾みをつけてくれる無料オンラインツール10選 | LANDR Blog
signal - Online MIDI Editor

最近こういう奴多いよな、なんか命令とか受けとんのか、カミカゼけ

Posted by funa : 05:46 PM | Web | Comment (0) | Trackback (0)


June 9, 2021

k8s
全て想像ですが
読み方はケーツと読みます、半端ねーてす、あるいは半端ネース

ケツが扱う最小単位がPodで1つの機能を持つ(Podは1つ以上のコンテナを含む)
ReplicaSetは複数のPodを組み合わせてアプリを実現する(Podの数の管理機能)
DeploymentはReplicaSetを管理、アップデートの際は新規ReplicaSetを作成してバージョン更新を行う(Podのデプロイ管理機能)
ServiceはDeploymentに対してIPアドレスやLBを設定してサービス提供する(Podへのアクセス管理機能)
クラスターはServiceが複数動く環境、少なくとも1つのMaster(node)と複数のNodeから構成され
 Nodeはコンテナを動かす為のサーバ、MasterはNodeを管理しスケジューリングやオートスケールを行う
 (非マネージドなら単一障害点にならないようマルチMaster3台が一般的)
cluster > namespace > node x workload (pod, <複数pod:deployment, job, statefulset>, <全てのnodeにpod:deamonset>)
 namespaceは論理的な分離、node poolは物理ノード・スケーリング管理

■ケツリソース一覧
Node:Kubernetes クラスタで実行するコンテナを配置するためのサーバ
Namespace:Kubernetes クラスタ内で作る仮想的なクラスタ
Pod:コンテナ集合体の単位で、コンテナを実行する方法を定義する
ReplicaSet:同じ仕様のPodを複数生成・管理する
Deployment:Replica Setの世代管理をする
Service:Podの集合にアクセスするための経路を定義する
Ingress:Service を Kubernetes クラスタの外に公開する
ConfigMap:情報を定義し、Podに供給する
PersistentVolume:Podが利用するストレージのサイズや種別を定義する
PersistentVolumeClaim:PersistentVolumeを動的に確保する
StorageClass:PersistentVolumeが確保するストレージの種類を定義する
StatefulSet:同じ仕様で一意性のあるPodを複数生成・管理する
Job:常駐目的ではない複数のPodを作成し、正常終了することを保証する
Cronjob:cron記法でスケジューリングして実行されるJob
Secret:認証情報等の機密データを定義する
Role:Namespace 内で操作可能な Kubernetes リソースのルールを定義する
RoleBinding:Role と Kubernetes リソースを利用するユーザーを紐づける
ClusterRole:Cluster 全体で操作可能な Kubernetes リソースのルールを定義する
Cluster RoleBinding:ClusterRole と Kubernetes リソースを利用するユーザーを紐づける
Service Account:Podに Kubernetes リソースを操作させる際に利用するユーザー

流れ
 Dockerfile(設定)とアプリをdocker build/pushし
 DockerレジストリにDockerイメージを作成
 GKEにデプロイ(deploymentファイル.yml/serviceファイル.ymlをkubectrl create/apply:manifest)
  レプリケーションコントローラ:Pod数、オートスケールをdeployment fileで設定
  サービス定義:ノードのproxyデーモンが複数Podに負荷分散
   ノードがクラスタ内のPod同士に振分けるクラスタIP
 LBが振分ける外部IPを設定
K8s
 クラスタリング(複数サーバを束ねる)
  コールドスタンバイ、ホットスタンバイ(フェイルオーバ)
   オーケストレーション…NW、Storage、スケジュール、IP、ルーティング、負荷分散、監視、デプロイ(ローリングアップデート)
 構成
  マスターサーバ(コントロールプレーン)←kubectrl
   etcd(DB:kvs形式のconfig=マニフェスト、デプロイメントとサービス等を記述)
  レジストリサーバ(コンテナレジストリ:GCSに保存)
  ↓
  ワーカーノード>Pod>コンテナ(webサーバ)、コンテナ(ログ収集)、仮想NIC
  ワーカーノード、ワーカーノード…
GKE
 コンソールで設定+kubectrl
  コンソール:GCE、ストレージ、タスクキュー、BQ、cloudSQL、cloudDataStore、cloudソースレポジトリ、StackDriverLogging、StackDriverMonitoring、StackDriverTrace、CloudPlatform、BigTable、Pub/Sub、サービスコントロール、サービス管理
※コンソールだけでkubectrl無しでイケそう
 クラスタ作成>ワークロードでコンテナデプロイ、あるいは直接デプロイで簡易でイケる
 クラスタ作成をすると一般公開で承認NW、あるいは限定公開、はたまたIP範囲とか詳細を決められる

■流れ
 GKEでクラスタを作成
 Kubectrlをインスコ
 KubectlでPodを立ち上げ>Deploymentができる、複数Podの起動も
 Kubectlでサービス公開設定
【GCP入門編・第7回】Google Container Engine (GKE) での Docker イメージの立ち上げ方 | 株式会社トップゲート (topgate.co.jp)

 サービスアカウント作成
 ネームスペース、kubeサービスアカウント作成
 Yamlで機能を宣言しKubectlでデプロイ

Pod(論理ホスト/インスタンスみたいな)
 一意のIPが自動的に割り当てられる、Pod間はIPで通信
 Pod内のコンテナはlocalhost:ポートで互いに通信、コンテナ間で共有するストレージ
 Podを直接作成は非推奨
 CPU/メモリの最小と最大を設定

k8sのsecretリソース(≒SA key)はPw/Oauthトークン/SSH key等を含むオブジェクト(base64エンコード生)
 使う方法3種類:コンテナにマウント、コンテナの環境変数、Pod生成時にケツがpull
  どこに置くか、どう暗号化するか、gitに置かない等の考慮が必要
別途記載がある
/// BANGBOO BLOG /// - GCP part2
/// BANGBOO BLOG /// - GKE

=========
時間の掛かっていた処理をクラスタ構成で並列処理させて早く終わらすとか
ケツのツールを入れるとか、例えばArgoワークフローでデプロイ/デリバリー/バッチスケジューラを動かす
 DAG:有向非巡回グラフのやつ
=========
helmを入れる(kubectrlを使うローカルに)とチャート記述でデプロイができる
 テンプレートがありマニュフェスト記述からkubectrlあたりのデプロイを省力化できる
=========
masterとworkerで構成され冗長化を考慮すると最低master3台、worker2台~のサーバ要るのでマージドが楽
コンテナにはストレージを置かず外部に持たせた方が良いかも(ステートレスでファイルを保持しない)
DBはK8s上でなくマネージドサービスを使いたい
=========
VMからOSを抜いてアプリを入れたものがコンテナ、ドッカ―がOS以下を手配
Dockerがコンテナを管理、k8sがそのDockerをオーケストレーション
複数台でまとめたクラスターで故障があっても切り替え可用性を保つ
 そのクラスターをnamespaceで分割し複数チームで利用することも可
稼働中にサーバ追加のスケールをしたりロールバックできる
podにIPを割り振ったり、DNS名を振ったり、負荷分散したり
自動デプロイでコンテナイメージをサーバ群へ展開する
Dockerのホスト管理、コンテナのスケジューリング、ローリングアップデート、死活監視、ログ管理等々
Externalname>LoadBalancer>NodePort>ClusterIP
マネージド以外ならk8s用にユーザ管理も必要
Dockerはアプリイメージという感じ、それらを束ね管理するのがケーツ
Kubernetesとは?仕組みと構造をわかりやすく解説 - カゴヤのサーバー研究室 (kagoya.jp)
Kubernetesとは何かを図でわかりやすく解説!Pod、Na…|Udemy メディア (benesse.co.jp)
ケツは3か月ごとにアップデートされ知識もアップデート必要だし、バージョンによって機能が変わり古いコードが動かないこともあり大変らしい

=========
↓実際のアプリがないとイメージ沸かん
クイックスタート: 言語に固有のアプリのデプロイ  |  Kubernetes Engine ドキュメント  |  Google Cloud
コンテナ化されたウェブ アプリケーションのデプロイ  |  Kubernetes Engine  |  Google Cloud
Cloud buildを使用してアプリをコンテナイメージにパッケージ化
GKEでクラスタを作成、コンテナイメージをクラスタにデプロイ
↓手始め?
GKEでnginxを外部アクセス可能にするまで - Qiita
Kubernetesでのコンポーネント間の通信をまとめる - Qiita
GCP におけるコンテナ入門 ~Kubernetes の何がすごい!? | クラウドエース株式会社 (cloud-ace.jp)

GKE

これはいいかも
Objectsについて知る - オーケストレーションツール (y-ohgi.com)

GKEクラスタをコンソールで作成
NATを作成
Cloud shellを起動
k8s用の認証情報を取得
$ gcloud container clusters get-credentials <standard-cluster-1> --zone asia-northeast1-a
k8sオブジェクトを表示
$ kubectl get all
nginx dockerイメージを起動
$ kubectl run <handson> --image=nginx --port 80
LBを作成しトラフィックを流す設定
$ kubectl expose deploy <handson> --port=80 --target-port=80 --type=LoadBalancerサービスを表示(LBを見る)
$ kubectl get service
レプリカセットを表示
$ kubectl get replicaset
ポッドを表示
$ kubectl get pod
ポッドを削除
$ kubectl delete pod <handson-86f796b8b7-m68sr>
nginxコンテナ3台を立てる
$ kubectl run <handson-2> --image=nginx:1.14 --replicas=3
ポッドの詳細情報を表示
$ kubectl describe pod <handson-2-85dfb7fd88-wr58c>
デプロイメントを表示
$ kubectl get deployment
dockerイメージのバージョン変更
$ kubectl set image deployment <handson-3> <handson-3>=nginx:1.15
デプロイメントのレプリカセットの履歴を表示
$ kubectl rollout history deployment <handson-3>
$ kubectl rollout history deployment <handson-3> --revision=1
デプロイメントのロールバック(nginx:1.14に戻す)
$ kubectl rollout undo deployment <handson-3>
デプロイメントを削除
$ kubectl delete deploy/<handson-2>
サービスを削除
$ kubectl delete service <handson>

マニフェストを作成(デプロイメントとサービス)
vi manifest.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    run: handson-4
  name: handson-4
spec:
  selector:
    matchLabels:
      run: handson-4
  template:
    metadata:
      labels:
        run: handson-4
    spec:
      containers:
      - image: nginx
        name: handson-4
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  labels:
    run: handson-4
  name: handson-4
spec:
  ports:
  - port: 80
    targetPort: 80
  selector:
    run: handson-4
  type: LoadBalancer
マニフェストを適応(nginxとLBが作成される)
$ kubectl apply -f manifest.yaml
マニフェストで定義したオブジェクトを削除
$ kubectl delete -f manifest.yaml

Dockerfileの作成
$ vi Dockerfile
FROM google/cloud-sdk:latest
COPY . /app
RUN make app
CMD python /app/app.py
Dockerビルド
$ docker build -t myapp .
ビルドしたコンテナを起動
$ docker run -p 3000:3000 myapp
http://localhost:3000 へアクセスして確認
コンテナにタグ付け
$ docker tag myapp asia.gcr.io/${prjid}/myapp
GCRの認証
$ gcloud auth configure-docker
リポジトリへPush
$ docker push asia.gcr.io/${prjid}/myapp
デプロイ
$ kubectl run myapp --image=asia.gcr.io/${prjid}/myapp
$ kubectl expose deploy myapp --port=80 --target-port=3000 --type=LoadBalancer
ポッドを増やす
$ kubectl scale deployment myapp --replicas=3
確認
$ kubectl get all -l run=myapp

クラスタを削除
$ gcloud beta container clusters delete standard-cluster-1 --zone "asia-northeast1-a" 
Dockerイメージの削除
$ gcloud container images list --repository asia.gcr.io/${prjid}
Dockerイメージの削除
$ gcloud container images delete asia.gcr.io/${prjid}/<myapp>

GKEのクラスターでConnect>クレデンシャルcmdが分かる
gcloud contaier clusters get-credentials <clustername> --zone asia-northeast1-b --project unco
 そのコマンドを承認済みNWの環境で実行する
kubectl get pods -n <namespace> | grep xxx
 Podを特定したい、オプションnでネームスペース、-n無しだと現行のNS、--all-namespacesで全NS
kubectl exec -it <podname> -n <namespace> -- /bin/bash
 これでPodに入れるので python xxx.py とかコマンド可能
さらにアクセスが必要なら
kubectl config get-contexts
 コンテキスト一覧(クラスタ、ユーザ、ネームスペースを組み合わせたもの)を表示
kubectl config use-context <コンテキスト名>
 コンテキスト切り替え
kubectl port-forward service/<srv> 8080:80

 ポートフォワード先を設定
別ターミナルを立ち上げ
curl "http://localhost:8080/api/v1/namespaces/<namespace>/pods/<pod>"
curl --silent 127.0.0.1:8080 | head -n 10

Kubernetes API RESTのサブリソース
サブリソースとは通常のリソースの HTTP パスに追加でサフィックスを付与した特別な HTTP パス
Service proxy: /api/v1/namespaces/<namespace>/services/<scheme>:<service>:<port>/proxy/
Pod のログを取得する: /api/v1/namespaces/<namespace>/pods/<pod>/logs
Pod のポートを転送する: /api/v1/namespaces/<namespace>/pods/<pod>/portforward
Pod で任意のコマンドを実行する: /api/v1/namespaces/<namespace>/pods/<pod>/exe

=========================
ASM(anhtos service mesh)
 サービスメッシュでマイクロサービス間で適切な通信する
 マネージドな管理?監視/デプロイ/イングレスセキュリティ?コントロールプレーン?
  DBやミドルウェアは外して別途管理が良いらしい
全体の雰囲気
サイドカープロキシ
 ASMがGKE本体に蜜結合することなくプロキシとして全てのトラフィックを傍受できる
 周辺的なタスクをこなすという意味合いか

=========================
●DAGを使う
Kubernetes ネイティブなワークフローエンジン Argo Workflows | 豆蔵デベロッパーサイト (mamezou-tech.com)
Argo公式マニフェストが長すぎる?argo-helmでやるか
argo-helm/charts/argo-workflows at main · argoproj/argo-helm · GitHub
Quick Start - Argo Workflows - The workflow engine for Kubernetes (argoproj.github.io)

gcloud builds submit --pack image=gcr.io/bangboo-run/unco ならDockerfile不要らしい

Posted by funa : 12:01 AM | Web | Comment (0) | Trackback (0)


May 22, 2021

GCP Hands Off
データの種類でアーキテクチャを決める?
 コンテナはオーバヘッドが少なくVM/GCEに比べ軽量高速、スケールアップ/ダウンに優れている
GCS
 IAPを使うと画像アクセスにも認証が使えそう>LBのバックエンドではIAPが使えない
  GCEにGCSマウントするとGCEのIAPとしてイケる、gcsfuseのOSSでLinux上のドライブになる
   CensOS6.8にgcsfuseをインストールしてGCSをマウント - Qiita
   GCS Fuseを使ってみる - Qiita
 リテンションで保護期間を設定したり、ライフサイクルで削除時期を設定したり
 世代管理ができたり

■制約が重要そうでまとめて記載したい
 IAPとCDNの両立はできない
 LBのbackendにgcsを設定したときはIAPが使えない
 GKEのingressのLBに他のアプリのバックエンドを同居できない(GKEが上書き自動更新するから、ドメイン別になる)
 IAPでGCEにOSログインする場合はAPI有効やIAPの設定、OSlogin系の権限が必要(Owner付与が楽)
 ネットにでるのがapt updateのみでもNAT/Routerが要る

■VPCネットワーク
default VPCネットワークを削除(セキュリティが緩いため)
vpcネットワーク作成 サブネットIPレンジ 10.27.0.0/16-192.168.27.0/24 等で
 private google accessはオンでいいのか?on
 FWはひとまずなしで、だが大体ポートは22,80,443,8080?
別途firewallで下記を設定(ちなみにリクエスト側を許可すればよく、レスポンス側は自動)
bangboo-fw-allow-iap-ssh IAPからのSSHを許可 35.235.240.0/20 tcp:22
 レンジはマニュアル https://cloud.google.com/iap/docs/using-tcp-forwarding#create-firewall-rule
bangboo-fw-allow-lb GFE(Google Front End)からのHTTPを許可 35.191.0.0/16,130.211.0.0/22 tcp:qll
 レンジはマニュアル https://cloud.google.com/load-balancing/docs/health-checks#fw-rule
Cloud NAT(Router)を設定
https://cloud-ace.jp/column/detail260/
https://www.topgate.co.jp/google-cloud-network-security

■ハンズオン(GAE:php+FW+IAP)→GAEよりCloud runが良い
IAPはGAEが簡単そう(アクセスするのにGoogleの認証プロンプトを出す)
 自前DNSにTXTレコードを設定>確認>IPが表示されAレコードやCnameも登録でき、SSL証明書も使えるようだ
  しかし無くてもgoogle提供のドメインが使え不要 DNS(TXTレコード)による所有権の確認 - Google Search Consoleの使い方 (howtonote.jp)
 WinローカルにGCP SDKインスコし下記にapp.yamlとindex.phpを置いてcmd→ gcloud app deploy
  C:\Users\おまはんのユッザー名\AppData\Local\Google\Cloud SDK\php
 IAPを有効にしIAM secured userの権限とIAMでGAE viewer権限付与で@gmail.comユーザ等は見れる
  外部ドメインを使うときはIdentityPlatform設定が必要そう
止めるにはinstanceを削除する(再度アクセスでinstanceが自動作成される)、IngressをInternal onlyにすると一応止まるか、楽だ

■ハンズオン(Marketplace: GCE+FW->Wordpress)
デフォルト:エフェメラル+インターネット公開なし(LB/IAP/NAT/Armor付けてから公開しようかと)
VMインスタンス ネットワークタグwordpress-1-deployment
FW:wordpress-allow-external ターゲットタグwordpress-1-deployment、ソース0.0.0.0/0 tcp0-65535
スナップショットのラベルはKVSで app : wordpress とか env : testとか
DBはステートフルMIG-永続ボリュームにできる?

■ハンズオン(GCE+nginx+FW+LB+IAP+Cloud NAT+Cloud armor)
●cloud shell terminal
gcloud compute instances list インスタンス一覧
●コンソール
デフォルトVPC NWを削除 > VPC NW作成 > サブネットIPレンジ 10.27.0.0/16-192.168.27.0/24等で
GCE VMを作成(Instance scheduleで起動-停止時間が入れられる、テンプレやグループに使えない?)
 インスタンスを作って設定しスナップショットからOSイメージを作り量産すればいいが
  instance template作成してinstance group作成してもいい。IGが中々できないならIGを開きエラーメッセージを見ること
 OSはubuntu、API access scopeには"Allow full access to all Cloud APis"で
  外部からアクセスさせずLB経由だけにしたい→外部IPがephemeralで止められない→作成時にnetwork>external ipをnoneで作成すること→
  外へでれなくなるのでgcloudコマンドが通らない→CloudNAT(Router)も設定
 インスタンステンプレートのメタデータ
  起動スクリプトをファイル化できる
   キーstartup-script or shutdown-script、値にパス
   キーstartup-script-url or shutdown-script-url、値にGCSのURL
  OSLoginをIAPにしてVM上の独自ID管理PW管理不要に
   便利機能「OS Login」を使ってIAMでインスタンスへのSSH接続制限をする | apps-gcp.com
   キーenable-oslogin、値にTRUE、IAMで権限(compute OSLogin/IAP tunnel/gce系)、IAP API有効
    権限もIAMで管理されるのでLINUX上の755等も不要なようだ(computeinstanceAdmin.v1を付けとく)
  MIGとLBと同じヘルスチェックを使うことは非推奨
   LBはより短い低い閾値にせよ
SSHの項目からview gcloud commandで好きなSSHターミナルからアクセスできるcmd出る
 gcloud beta compute ssh --zone "asia-northeaset1-b" "instance-3" --tunnel -through-iap --project "bangboo-sandbox"
●SSHターミナル
gcloud init インスコ
sudo apt-get install nginx Webサーバインスコ、ブラウザで内部IPでアクセスしたかったが不可だった
sudo service nginx stop 止める、動かすのは sudo service nginx start
ps プロセス見る
curl http://10.117.0.19 nginxが動いているか確認
cat /var/log/nginx/access.log ログ確認
●nginx
/etc/nginxにあるconf系が設定ファイル
sites-enabled/default だけがあり cat default しdocument rootは/var/www/htmlと判明
 ここへ移動 cd /var/www/html
sudo cp index.nginx-debian.html index.html コピー
sudo nano index.html で編集
設定変更後は sudo service nginx restart
●コンソール
GCEスナップショット作成→OSイメージ作成→テンプレ作成→Healthcheck作成→MIG設定
 OSイメージはオンプレから作ったものとかHashi corpのPackerで作るとかも
FW作成
 gceに外部IPがあればアクセス試す
 fw-bangboo-http-ingress-allow ingress - "all instances" - 0.0.0.0/0 デフォルトで許可+ingressが必要
  httpsはIPではダメ、ドメイン/証明書が要るか知らんがhttpでは外部IPあればアクセスできる
   GCPのIPを自前のDNSのAレコードに設定しとけば、、
   ウェブとメールを別々のサーバで運営したい?・・・それ、ゾーン設定で出来ます! | さくらのナレッジ (sakura.ad.jp)
   ドメイン所有はDNSにTXTレコード設定ができるようだが、、、
   ウェブマスター セントラル (google.com)
  使うときfw-bangboo-all-ingress-allow ingress - "all instances" - 192.168.1.255/32 に設定?
 外部IP(普通LBとなるか)への制御はCloud armorのでdeny allowしてFWではあんまり考慮しない
  armor-bangboo-all-ingress-deny ingress - "all instances" - 0.0.0.0/0 で設定完了まで止めとく
LB作成
 VMインスタンスグループ(子インスタンス)作成(上で作ってなければ)
  インスタンステンプレート作成
 LBヘルスチェック(閾値)が要る
 httpLBだと内部か外部か選択できる
  httpLBならIPレンジが要る>VPC networkで同resionで使われていないものを設定
  例10.55.20.0/22なら10.55.23.255まで使われているので10.55.25から使うとか
  NW計算 ネットワーク計算ツール・CIDR計算ツール | Softel labs
   VPCのサブネット設定は拡大できるが縮小ができない→小さめにしておきたいが、k8sはIP沢山使うので大きめ
   プライベートサービスコネクト(VPC間を繋ぐ)を使うと疎結合でつなげられるが
 backendはhttpで、healthcheckはtcp80とproxy無し
IAP作成
 外部 HTTPS ロードバランサの設定  |  Identity-Aware Proxy  |  Google Cloud
 IAP(https)を見るとFWで開けてくれの指定がある
  fw-bangboo-lb-gce-allow Source IP range:072.72.1.19/22, 69.11.8.0/16 tcp:80
 IAPを見るとLBを設定するとFWはLBに対するものだけになるので不要との指示がある
  fw-bangboo-http-ingress-allow 0.0.0.0/0(削除)
  下記はインスタンス作成時の許可設定分で不要
   default-allow-internal 69.11.0.0/9(削除) default-allow-http 0.0.0.0/0(削除)
   これも不要?default-allow-http 0.0.0.0/0 tcp:443(削除)default-allow-icmp 0.0.0.0/0(削除)
   default-allow-rdp 0.0.0.0/0 tcp:3389(削除)default-allow-ssh 0.0.0.0/0 tcp:22(削除)
 IAP(ssh/tcp)を見るとFWで開けてくれの指定があるが開けるとhttpsに穴ができると出るし止め
  fw-bangboo-lb-iap-tcp-allow  Source IP range:072.72.2.0/20 tcp:all(sshターミナルを使う時だけFW開ける、通常priority9000)
 IAPをONだけでは駄目で、FWで調整してGCEに直接アクセスじゃなくLBでやっとIAPが動くみたい
  IAPの設定でhttp://IPでアクセスするとhttps://に転送されたのだが(IAPがない場合は下記設定をするようだ)
  HTTP(S) 負荷分散用の HTTP から HTTPS へのリダイレクトの設定  |  Google Cloud
事前にgce.bangoo.com -> 117.072.19.255 (LBのIPはephemeralをstaticに変更)を自前のDNSに設定
 (DNSのTTLを前日に3600から300に変更しておいたり、DNS反映期間があったり)
 LBのフロントエンドでマネージド証明書を設定(ssl-policyを緩めで設定したが必要?)
  オレオレ証明書は?
 LBフロントエンドはhttpsでもバックエンドはhttpで
 IAP-secured web app userロールを@gmail.comユーザに付与
 IAPとCDNの両立はできない
 LBのbackendにgcsを設定したときはIAPが使えない→ネット公開にしてVPN SCで制御?(元々ネットに面しているが権限がないだけ)、GCEにGCSをマウント?
FW調整
 0.0.0.0/0 all deny priority2000>LB関連 tcp80 allow 1000/IAP関連 tcp allow 1000>(使用拠点のソースIP allow 500)
  使用拠点のIPはLBを使うならArmorで設定すればFWへの設定不要
 GCEの外部IPを止める:インスタンステンプレート作成時に外部IPnoneで設定(StaticIPを買って削除でもnoneにできなさそう)
 必要なもの以外を止める:0-442, 444-65535で443のみ許可は駄目か?
 Connectivity testでテストがIPアドレス等でできる(設定変更から実際の反映に時間が掛かるものがあるような気が)
apache benchでスケールするかテスト Apache Bench を使って初めてのベンチマークテスト - Qiita
 sudo apt install apache2 abはapachに含まれるのでどれかのVMにインスコ
 ab -n 1000 -c 100 https://gcp.bangboo.com/ でインスタンスが増えることが確認できる
Cloud armor設定
 DDoS等を防ぐのでOnでいいのでは、adaptive protectionで優先度低いdeny設定
 外部IPのdeny allowはこれでやる(web app firewallなのでな)、log4J対策等もここで弾く
  一時止めるときは0.0.0.0/0 bad gateway等分かり易いエラーで止めるのが良いかも
 IAPが前、Cloud armorが後ろ、そしてLBとか
Access context manager設定(+VPC service control)
 Organizationの設定が必要(≒Cloud identityでドメイン必要?)IPアドレスやOS等でアクセスを制限できる
CloudSQL
 APIライブラリからCloud SQL API、Cloud SQL Admin APIを有効に
 平文通信→暗号化CloudSQL proxyバイナリをVMインスコ、ディレクトリ切る
  proxyとアプリ設定を合わせる、proxyサービス起動
 SQL用にsvac作成 lemp-gce-sql-01@
  ログインユーザをこのsvacにowner設定
  ロール付与 Cloud SQL Client、Compute Engine Service Agent、Compute Instance Admin (v1)、Compute Viewer
  このsvacをGCEインスタンスのデフォルトsvacに設定
 ユーザやdatabeseを作成、charaset: uft8mb4, collation: utf8mb4_bin
 GCEでSQL proxyの設定(SSH開く)
  gcloud auth list ログインユーザがsvacか確認
  mkdir $HOME/download
  cd $HOME/download
  wget https://dl.google.com/cloudsql/cloud_sql_proxy.linux.amd64
  sudo mv cloud_sql_proxy.linux.amd64 /usr/local/bin/cloud_sql_proxy 変名
  sudo chmod +x cloud_sql_proxy 実行権限設定
  sudo mkdir /cloudsqlproxy ソケットになるディレクトリ作成
  sudo chmod 777 /cloudsqlproxy パーミッション設定
  sudo /usr/local/bin/cloud_sql_proxy -dir=/cloudsqlproxy -instances=bangboo-sql:asia-northeast1:mysql-01
  ↑Readyになってからコマンドが返るのに何分か掛かる
  もう一つSSHを開くと下記コマンドが通る
  mysql -u root -p -S /cloudsqlproxy/bangboo-sql:asia-northeast1:mysql-01
  mysql> connect test;
  mysql> show tables;
  mysql> create table test.test (id int, name varchar(10));
  mysql> insert into test (id, name) values (1, 'baka');
  mysql> select * from test;
 SQL proxyサービス化 Cloud SQL Proxy (TCP Socket)を systemd で起動させる - Qiita
  sudo vi /etc/systemd/system/cloud_sql_proxy.service
===== 
[Unit]
Description = Cloud SQL Proxy Daemon
After = network.target
 
[Service]
ExecStart = /usr/local/bin/cloud_sql_proxy -dir=/cloudsqlproxy -instances=bangboo-sql:asia-northeast1:mysql-01
ExecStop = /bin/kill ${MAINPID}
ExecReload = /bin/kill -HUP ${MAINPID}
Restart = always
Type = simple
LimitNOFILE=65536
 
[Install]
WantedBy = multi-user.target
=====
  sudo systemctl start cloud_sql_proxy 起動だが自動設定してリブートだけでいい
  sudo systemctl enable cloud_sql_proxy サービス自動起動
  sudo reboot now
   Authenticating as: Ubuntu (ubuntu)でPWを求められる場合
    sudo su - でrootに切り替えてからcmd sudo su とかしてる人はだいたいおっさん (zenn.dev)
  systemctl list-units --type=service サービスの一覧確認
  systemctl list-units --all --type=service 全サービスの一覧確認
  service サービス名 status
  service サービス名 start
FW/ArmorでIngress全止め or VMインスタンス停止、LB停止

■GCE MIGローリング更新
dev-stg環境でinstance templateを作ってprodでテンプレ置き置き換える感じ?
  シングルVMでstg > OSイメージ > テンプレ化 > prod用MIGローリングアップデート設定
 MIGは徐々に更新をいい塩梅で行う必要があるためローリング更新する
 ロールバックはテンプレートを元に戻す設定をする、コミットは新しいテンプレートを設定するだけ
 カナリアは2nd テンプレート追加項目でターゲットサイズで3台とか10%とか設定するだけ
ローリング更新(Update VMS)
 インスタンスグループを開いてUpdate VMSに進む
 a)Proactiveは最大サージ(一時追加のインスタンス数)、とオフライン上限を指定
 b)日和見Opportunisticはオートスケールの増減時に新インスタンステンプレートに切替る(どうでもいいパッチ等)
 サージ:追加台数、オフライン:停止台数、
 オフライン台数を大きくすると一気に反映できる
 それに合わせて見積もりサージを大きくする(料金は掛かる)
  最大サージを 1、オフライン上限を 1 とすると、新しい VM が 1 ずつ発起動して、古い VM が 1 台ずつ落とされて行きます。
  最大サージを 3、オフライン上限を 2とすると、新しい VM が 3 発起動して、古い VM が 2 台落とされ、1台落とされる。
インスタンスの再起動/置換(Restart/Replace VMS)
 インスタンスグループを開いてRestart/Replace VMSに進むとローリングでインスタンスの再起動と置換ができる
 a)再起動:オフライン上限のみを指定して VM のテンプレートを切り替え
 b)置換:最大サージを指定することができるようになるだけ

■インスタンススケジュール
元来のサービスアカウントにcompute.instanceAdmin.v1が必要(コンソールでの設定時にエラーが出るので参考にして権限付与)
VMは一つのインスタンススケジュールにしか所属できないため、テスト後に本番スケジュールに入れなおす等の考慮が必要
インスタンススケジュールを削除するには、所属のVMを外す必要がある
最大15分遅れる場合がある。起動時間もその上加算する必要があるかも

■Monitoring
VMにOpsエージェント入れる
gcloud components update これ時間掛かるし不要では
https://cloud.google.com/stackdriver/docs/set-permissions.sh?hl=ja をダウンロード
terminalにアップロードし実行 bash set-permissions.sh --project=bangboo-ome
インスタンス ラベルで設定する GCEにラベルenv=test,app=omeを設定
gcloud beta compute instances \
    ops-agents policies create ops-agents-policy-safe-rollout \
    --agent-rules="type=logging,version=current-major,package-state=installed,enable-autoupgrade=true;type=metrics,version=current-major,package-state=installed,enable-autoupgrade=true" \
    --os-types=short-name=centos,version=7 \
    --group-labels=env=test,app=ome \
    --project=bangboo-ome
起動しているVMにOS Config エージェントがインストールされているかを確認
gcloud compute ssh instance-1 \
    --project bangboo-ome \
    -- sudo systemctl status google-osconfig-agent
下記が返る
Enter passphrase for key '/home/sute3/.ssh/google_compute_engine': 
 google-osconfig-agent.service - Google OSConfig Agent
   Loaded: loaded (/lib/systemd/system/google-osconfig-agent.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2022-04-11 18:34:26 UTC; 8min ago
 Main PID: 1279 (google_osconfig)
    Tasks: 11 (limit: 1116)
   CGroup: /system.slice/google-osconfig-agent.service
           └─1279 /usr/bin/google_osconfig_agent
Numpyが要る場合は下記でインスコ
sudo apt-get install python-numpy python-scipy python-matplotlib ipython ipython-notebook python-pandas python-sympy python-nose
ダッシュボード作成
アラート作成
複数の Cloud プロジェクトの指標を表示する  |  Cloud Monitoring  |  Google Cloud
 エージェントのログのモニタリングはNW構成に関わらず集約できる(GCP環境に置かれておりGCP設定のみでOKだから)
Yaml設定を新規で作ればオーバーライドされる
sudo vim /etc/google-cloud-ops-agent/config.yaml
------------------
logging:
  receivers:
    laravel_log:
      type: files
      include_paths:
        - /var/www/html/laravel/storage/logs/*.log

  service:
    pipelines:
      custom_pipeline:
        receivers: [laravel_log]
-----------------
# 反映
sudo service google-cloud-ops-agent restart


sute16 asia-northeast1-b 2021/7/24(91日で33000yen-10/20位まで)
sute3 asia-northeast1-b 2022/2/20(91日で34500yen-5/20位まで)
Instance groupはどう止める?>LB削除>LBのバックエンド削除>Instance group削除
 LBはinstance groupがいる、IAPはGCEの場合はLBにSSL証明書要る(ドメインもGlobalIPも要る)
  DNSのAレコードを登録しLB設定すれば証明書入る
   毎回検証終了時につぶして、立てるのが面倒そうだな→FWでdeny allしとく
 【初心者】GCP Identity-Aware Proxy (IAP), Access Context Managerを使ってみる (WEBサーバへのアクセス制限) - Qiita
 Oauth同意画面のサポートメールはログインしているユーザのものか、そいつがオーナになっているGoogle workspaceのメールグループを設定することができる(gcpのロールとしてwnerかoauthconfig.editorも要る)

nginx+PHP appサーバ+BigQuery+BigTable+CloudSQL(MySQL)+GCS+α?
 [PHP]BigQueryのデータを取得する | yyuuiikk blog
$ composer require google/cloud でインスコ
<?php
require 'vendor/autoload.php';
use Google\Cloud\BigQuery\BigQueryClient;
$keyfile = './credential.json'; //svacのkey
$bigquery = new BigQueryClient([
    'keyFile' => json_decode(file_get_contents($keyfile), true),
]);
$dataset = $bigquery->dataset('dataset-name');
$table = $dataset->table('table-name');
$queryJobConfig = $bigquery->query(
    "SELECT * FROM `project-id.data-set-name.table-name` LIMIT 100"
);
$queryResults = $bigquery->runQuery($queryJobConfig);
foreach ($queryResults as $row) {
    print_r($row);
}
Google Cloud Storage にPHPを使ってファイルをアップロードする | カバの樹 (kabanoki.net)
$composer require google/cloud-storage でインスコ
<?php
require __DIR__ . '/vendor/autoload.php';
use Google\Cloud\Storage\StorageClient;
$projectId = 'bangboo-prj';
$auth_key = './iam/credential.json';
$bucket_name = 'gcs-bangboo';
$path = 'img.png';
$storage = new StorageClient([
   'projectId' => $projectId,
   'keyFile' => json_decode(file_get_contents($auth_key, TRUE), true)
]);
$bucket = $storage->bucket($bucket_name);
$options = [
   'name' => $path
];
$object = $bucket->upload(
   fopen("{$path}", 'r'),
   $options
);
<img src="https://storage.googleapis.com/gcs-bangboo/img.png">
SSLに対応したNGINXリバースプロキシを構築する手順 - Qiita
 nginxは静的コンテンツを高速に配信するように設計されている。 また、 リバースプロキシ の機能を持つため、背後にWebアプリケーションサーバを配置して動的なコンテンツを配信したり、ソフトウェア ロードバランサやHTTPキャッシュとしても使うこともできる。
GCPにセキュアな踏み台サーバーを作成する. GCPのIdentity-Aware… | by Taiga Murakami | google-cloud-jp | Medium
 Googleにバックドアを開けてしまっては危険、、、ということはない


End

Posted by funa : 12:00 AM | Web | Comment (0) | Trackback (0)


Navi: <  1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14  >
PhotoGallery


TWITTER
Search

Mobile
QR for cellphone  QR for smart phone
For mobile click here
For smart phone click here
Popular Page
#1Web
#2Hiace 200
#3Gadget
#4The beginning of CSSレイアウト
#5Column
#6Web font test
#7Ora Ora Ora Ora Ora
#8Wifi cam
#9みたらし団子
#10Arcade Controller
#11G Suite
#12PC SPEC 2012.8
#13Javascript
#14REMIX DTM DAW - Acid
#15RSS Radio
#16Optimost
#17通話SIM
#18Attachment
#19Summer time blues
#20Enigma
#21Git
#22Warning!! Page Expired.
#23Speaker
#24Darwinian Theory Of Evolution
#25AV首相
#26htaccess mod_rewite
#27/// BANGBOO BLOG /// From 2016-01-01 To 2016-01-31
#28竹書房
#29F☆ck CSS
#30Automobile Inspection
#31No ID
#32Win7 / Win10 Insco
#33Speaker
#34Arcade Controller
#35Agile
#36G Suite
#37Personal Information Privacy Act
#38Europe
#39Warning!! Page Expired.
#40GoogleMap Moblile
#41CSS Selectors
#42MySQL DB Database
#43Ant
#44☆od damnit
#45Teeth Teeth
#46Itinerary with a eurail pass
#47PHP Developer
#48Affiliate
#49/// BANGBOO BLOG /// From 2019-01-01 To 2019-01-31
#50/// BANGBOO BLOG /// From 2019-09-01 To 2019-09-30
#51/// BANGBOO BLOG /// On 2020-03-01
#52/// BANGBOO BLOG /// On 2020-04-01
#53Windows env tips
#54恐慌からの脱出方法
#55MARUTAI
#56A Rainbow Between Clouds‏
#57ER
#58PDF in cellphone with microSD
#59DJ
#60ICOCA
#61Departures
#62Update your home page
#63CSS Grid
#64恐慌からの脱出方法
#65ハチロクカフェ
#66/// BANGBOO BLOG /// On 2016-03-31
#67/// BANGBOO BLOG /// From 2017-02-01 To 2017-02-28
#68/// BANGBOO BLOG /// From 2019-07-01 To 2019-07-31
#69/// BANGBOO BLOG /// From 2019-10-01 To 2019-10-31
#70/// BANGBOO BLOG /// On 2020-01-21
#71Bike
#72Where Hiphop lives!!
#73The team that always wins
#74Tora Tora Tora
#75Blog Ping
#76無料ストレージ
#77jQuery - write less, do more.
#78Adobe Premire6.0 (Guru R.I.P.)
#79PC SPEC 2007.7
#80Google Sitemap
#81Information privacy & antispam law
#82Wifi security camera with solar panel & small battery
#83Hope get back to normal
#84Vice versa
#85ハイエースのメンテ
#86Camoufla
#87α7Ⅱ
#88Jack up Hiace
#89Fucking tire
#90Big D
#914 Pole Plug
#925-year-old shit
#93Emancipation Proclamation
#94Windows env tips
#95Meritocracy
#96Focus zone
#97Raspberry Pi
#98Mind Control
#99Interview
#100Branding Excellent
Category
Recent Entry
Trackback
Comment
Archive
<     November 2024     >
Sun Mon Tue Wed Thi Fri Sat
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Link