/// BANGBOO BLOG ///

/// BANGBOO BLOG ///
■21/12/25 5:46PM
リンク踏合組合
シンプルで軽量！新しい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)

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

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

Comment (0)

■21/12/2 12:16AM
B=AIDMA R MAT SURE
フォッグの消費者行動モデル　B=MAT
行動Behavior = 動機Motivation（やりたい:利） × 実行能力Ability（簡単そう） × きっかけTrigger（背中押し）
https://note.com/akira_miyazaki/n/nb32211b94102

お気にのAIDMA
[Click for image]
他にも亜種が
AISAS / AISCEAS / AIDA / AIDCA / AIDCAS / AMTUL / SIPS / AISA / ARCAS / AIDEES / SAIDCAS

AIDMAと外的動機づけ(褒美Reward)と内的動機づけ(Fogg)とで人は動いている
　B=AIDMA R MAT

@2020-01-16

================
■行動経済学の使い方
人の意思決定の癖
１）プロスペクト理論：確実性が高いものが好まれる、損失は嫌いで回避される
２）現在バイアス：今この時点の自分は可愛い、時間が必要な効用の期待は割り引かれる
３）社会的選好：互恵性があり自分だけが得することも損することも避ける
４）ヒューリスティックス：直感的意思決定、人はサンクコストに耐えられない、極端も無理で平均的なものを選択しがち

人は合理的な意思決定はせず(馬鹿だから期待値が最大の所でなく)予測可能な所にずれる
　→医者は患者が正しい判断をしてくれるよう口説きたい（ナッジで合理的意思決定に誘導したい）

パチンコ/競馬/宝くじ/保険は胴元が儲かるように設計されている
　→他人に合理的に判断させないようにして、その分を利益として分捕りたい（スラッジ）

●「確実でコレを逃すと損をします、貴方は正しく貴方の所有物の価値は高いですが、コレは利己的ではなく、どう見てもこの選択が正しく見える」あるいは「コレは損するので避けて」というフレーミングを使う
●期待値でビジネスを計算し、ズラした分を利益として分捕る
●アンカリング(時間の単位や金額の単位、労働量の単位等の単位が人の意識の中にある)で参照点を上げ下げし利益を最大化する
●何もしなければ人は現状維持で、先延ばしするので利益をもたらしてくれるよう働きかけ続ける
●互恵性で貴方が施せば相手も少し返してくれる、これを続けることで関係性を築き、長期で利益を確保する
●間接税みたいな間接徴収にして幾ら払っているか分かりにくくする、メンテ費が掛かる等

使い方
1) 意思決定のプロセスを図式化2) バイアスを推測（能動的、受動的自動的、情報ソースetc)3) ナッジ候補を考える4) ナッジ候補上位をテスト実行5) 効果測定6) 全体に適用する

Comment (0)

■21/6/9 12:01AM
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記法でスケジューリングして実行されるJobSecret：認証情報等の機密データを定義する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
[Click for image]
これはいいかも
Objectsについて知る - オーケストレーションツール (y-ohgi.com)

GKEクラスタをコンソールで作成
NATを作成
Cloud shellを起動
k8s用の認証情報を取得$ gcloud container clusters get-credentials <standard-cluster-1> --zone asia-northeast1-ak8sオブジェクトを表示$ kubectl get allnginx dockerイメージを起動$ kubectl run <handson> --image=nginx --port 80LBを作成しトラフィックを流す設定$ 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 deploymentdockerイメージのバージョン変更$ 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.pyDockerビルド$ docker build -t myapp .ビルドしたコンテナを起動$ docker run -p 3000:3000 myapphttp://localhost:3000 へアクセスして確認コンテナにタグ付け$ docker tag myapp asia.gcr.io/${prjid}/myappGCRの認証$ 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で全NSkubectl 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>/logsPod のポートを転送する: /api/v1/namespaces/<namespace>/pods/<pod>/portforwardPod で任意のコマンドを実行する: /api/v1/namespaces/<namespace>/pods/<pod>/exe

コンテナ起動時• ステートレスな状態を維持する• スケールアウト可能なアーキテクチャにする• 設定は外部から注入できるようにする• ログは標準出力に構造化ログで出力する• いつでも容易に停止できるようにする• SIGTERM シグナルをハンドリングする• コンテナ上には単一プロセスのみ起動する• ヘルスチェック用のエンドポイントを用意する• アプリケーションの状態を可観測にする• 起動時にアプリをダウンロードしない
=========================
ASM（anhtos service mesh)　サービスメッシュでマイクロサービス間で適切な通信する　マネージドな管理？監視/デプロイ/イングレスセキュリティ？コントロールプレーン？
　　DBやミドルウェアは外して別途管理が良いらしいAnthos Service Mesh を導入、移行、そして使いこなしてみよう全体の雰囲気GKEクラスタへのAnthos Service Meshの導入 (zenn.dev)サイドカープロキシ　ASMがGKE本体に蜜結合することなくプロキシとして全てのトラフィックを傍受できる　周辺的なタスクをこなすという意味合いかAnthos Service Mesh を使用してサイドカープロキシを挿入する | Google Cloud
=========================
●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不要らしい

Comment (0)

Navi: < 12 | 13 | 14 | 15 >

-Home
-Column [133]
-Europe [9]
-Gadget [77]
-Web [137]
-Bike [4]

@/// BANGBOO BLOG ///