■24/2/20 10:03PM
駐輪禁止
おぢへ（頂き女子から"愛を込めて"、ギバー/マッチャーへ）【プレビュー】１ヶ月1000万頂く頂き女子りりちゃんの【みんなを稼がせるマニュアル】
[Click for image]
Prohibition of parking bike in Kobe
■チャリ禁止事項
令和6年（2024年）11月から罰則ながら運転禁止 スマホ（ハンズフリーを除く） 傘さし イヤホン等で安全な運転に必要な音又は声が聞こえない状態自転車の酒気帯び運転禁止 酒類提供のほう助も禁止他には 並進運転禁止
2人乗り禁止
車と同じ
夜間ライトが必要
一時停止は必要
一方通行、歩行者専用道路も適用
見通しの悪い交差点は徐行 車道左側通行が必要
兵庫県警察 自転車に係る主な交通ルール等(その他の主なルール)青切符は2025か2026のどこかで導入される
■リンは腎臓に悪い１）茹でて湯は捨てる２）大豆などの植物性食品からたんぱく質を摂取する（大豆の有機リンはフィチン酸で人間の腸からは吸収されない、肉や魚はリンが多い）[Click for image]
Comment (0)
■24/1/14 9:59PM
GKE
モダンか何か知らんが、豚玉かイカ玉で十分じゃ
＝＝＝＝＝＝＝＝＝＝＝
kubectlチートシート | Kubernetes
フォルダに .py と requirements.txt と .dockerignore と Dockerfile を入れてアップロードしているgcloud builds submit --tag asia-northeast2-docker.pkg.dev/bangboo-prj/xxx/image001
helloworld@bangboo-prj.iam.gserviceaccount.com 作成アクセス元のIPを確認するCloud run作成 ドメインないと無理なのでLBとIAPをあきらめ生成されるURLで十分 Cloud runでアクセス元IPを表示するヤツ runのallUsersのinvokerを削除したらアクセス不可になった（この方法で管理する）curl http://ifconfig.me/ で十分だったが
GKE
k8sの内部NWは通常別途いるがGKEは速い奴が動作
GKEはクラスタ内部のDNSでサービス名で名前解決できる
サービスのIPとポートは環境変数で参照可
kubectlを使うには、gcloud container cluters get-credentials を打つ必要がある
GKE設定-クラスタ:側の設定（IP範囲とかセキュリティとか？） 一般/限定公開:外部IPを使うか使わないか コントロール プレーン承認済みネットワーク：CPにアクセスできるセキュリティ範囲-ワークロード:マニフェストで設定
一般か限定公開か？コントロールプレーンが外部IPか？CPがグローバルアクセス可か？承認NWか？ 一般公開で承認NWが良いのでは？簡単だし、 限定公開で使うには＞CPに外部IPで承認NWでいいのでは？ NW:default subnet:default 外部IPでアクセス許可 CP アドレスの範囲 192.168.1.0/28とか172.16.0.0/28(サブネット重複しない奴) コントロール プレーン承認済みネットワーク home (169.99.99.0/24ではなくGCPのIPぽい) 限定公開ならnatが要る CPの VPCのIP範囲は、クラスタの VPC 内のサブネットと重複不可。CPとクラスタは VPC ピアリングを使用してプライベートで通信します グローバルアクセスは別リージョンからという意味っぽい、cloud shellからのkubectlのためONが良いデフォルト設定なら作成したサブネットのIP範囲でなくクラスタが作られない 面倒ならdefault-defaultで良いかも
サブネットをVPCネットワークを考えて指定する方が偉いかも知れんがdefault asia-northeast2 10.174.0.0/20 の場合 サブネットは asia-northeast2 10.174.27.0/24 とか
ARにあるコンテナからGKEをデプロイが簡単にできるCloud Source Repositories でソース管理gitが下記のようにできる gcloud source repos clone bangboo-registry --project=bangboo-prj cd bangboo-registry git push -u origin masterrun使用中のコンテナがGKE上では上手くいかない runのコンテナは8080のようだ Dockerfileとmain.py上ではポートは何でもよい仕様だが、runで自動的に8080割り当てるようだ それが駄目でありGKEは環境変数でPORT 8080を指定 CrashLoopBackOff問題がでる https://www.scsk.jp/sp/sysdig/blog/container_security/content_7.htmlデプロイ公開でポート80 ターゲットポート8080に（クラスタを作成後、ワークロードでデプロイする）
developmentのspec: containers: ports: - containerPort: 8080 を入れる？ yamlでなく、コンソールで設定時に入れると良い
$ kubectl get allNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEservice/flask-1-service LoadBalancer 10.48.4.134 34.97.169.72 80:32147/TCP 20m
us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0 これは簡単に上手く行く、環境変数PORT8080不要 クイックスタート: アプリを GKE クラスタにデプロイする | Google Kubernetes Engine (GKE) | Google Cloud
ワークロードでyamlの spec: replicas: 0を保存するとアクセスを止められる
コンフィグマップ：構成ファイル、コマンドライン引数、環境変数、ポート番号を別途持っていてPodにバインドする(マニフェストに書くと抜き出され見れる)シークレット：Base64の値？(マニフェストに書くと抜き出され見れる）甘いのでsecret mgrを使う方が良い？ config map/secretはマニフェストで編集する必要がある（見れるだけと思われる）エディタで見てみる：yamlとかステータスが見れる
■LBに静的IPを振る
GKE で Ingress を使用して Google マネージド SSL 証明書を使用した外部 HTTP(S) ロードバランサを作成する - G-gen Tech Bloghello-app-addressと名付けたIPを取得LBのアノテーションで設定# ingress.yaml（NWはNodePort、RouteapiVersion: networking.k8s.io/v1kind: Ingressmetadata: name: hello-ingress namespace: default annotations: kubernetes.io/ingress.global-static-ip-name: hello-app-address # IP networking.gke.io/managed-certificates: hello-managed-cert # 証明書 kubernetes.io/ingress.class: "gce" # 外部 HTTP(S)LBspec: defaultBackend: service: name: hello-deployment port: number: 8080
GKEでロードバランサのIPを指定するとき、グローバルに属するIPアドレスリソースは使用できないので注意 #GoogleCloud - QiitaServiceのLBはリージョン指定するタイプの静的IPIngressはグローバルIPOKapiVersion: v1kind: Servicemetadata: name: hoge labels: app: hogespec: ports: - port: 80 selector: app: hoge tier: frontend environment : stage type: LoadBalancer loadBalancerIP: xxx.xxx.xxx.xxx
ArmorでIP制限１）サービスから対象を選択しingressを作成することでLBを追加しArmorも設定可能２）デフォルトLBに付けるにはkubectl要りそう、backendconfig.yamlはどこに置く Cloud ArmorでGKE IngressへのアクセスをIPで制御する #GoogleCloud - Qiitaサービス画面のkubectrlから# backend-config.yaml を作り kubectl apply -f backend-config.yamlapiVersion: cloud.google.com/v1kind: BackendConfigmetadata: namespace: default name: hello-backend-configspec: securityPolicy: name: "bangboo-armor"
serviceのyamlに下記を追加metadata: annotations: cloud.google.com/backend-config: '{"ports": {"8080":"hello-backend-config"}}'↑これでは不足する どこで設定状態を見るか？ingress作成してLBとArmorつけて、デフォルトLBを削除してみる？
GKEの外部からのアクセスを制限するには？ 限定公開＋コントロールプレーンは承認済み等でアクセスしKubectlする ArmorでIP制限＋アダプティブ設定（ArmorはLBが要る）
GKEでNodePort TypeのServiceに対してインターネットアクセス許可する - IK.AM
限定公開クラスタ＋踏み台サーバにIAPで入りKubectl（承認済みNWでの制御はIPのみなので危ういらしい）
GKE(Google Kubernetes Engine) Autopilotの限定公開クラスタにIAPを利用してアクセスする | Tech-Tech (nddhq.co.jp)
【GKE/Terraform】外部ネットワークからの全てのアクセスを制限した限定公開クラスタを作成し、踏み台サーバーからkubectlする (zenn.dev)
コントロールプレーンとPod間で自動FWされない場合もありFirewall要チェック
Cloud shellのグローバルIPを取得しシェルを承認済みNWにできないか？＞OK curl http://ifconfig.me/
GKEでPythonをCron定期実行させたいArgoでDAGを実行させたい https://zenn.dev/ring_belle/articles/2c4bbe4365b544ArgoでGKEのCICD（Argoは別ホストでGithubにアクセスし、GKEを操る） https://www.asobou.co.jp/blog/web/argo-cd
サービスアカウント
Workload Identity Federation for GKEの新しい設定方法を解説 - G-gen Tech Blog
１）ノードに紐付いたサービスアカウントKSAをそのまま使用する(裏でimpersonate）
gkeのサービスアカウントとIAMサービスアカウントの紐づけが不要になった
VPCサービスコントロールで管理したい場合impersonateのSAを指定できないためWIFが要る２）サービスアカウントのキーを Kubernetes Secret として GKE クラスタに登録する３）Workload Identity Federationをつかう
GCP の Workload Identity サービスについてのまとめ #GoogleCloud - Qiita
Githubとか外部のサービスから利用するためSAを連携させる
IAM＞Workload identity連携画面で設定が見れる※KSAはノード単位で設定、Pod単位でGCPのリソースにアクセスできるように管理したい？
●メモ
忙しいときはスケールアウトするが、落ち着き始めるとスケールinし、必要なPodも落とされてしまう
safe-to-evict をymlのannotationで明示して特定Podはスケールinしない等にしておくannotations: cluster-autoscaler.kubernetes.io/safe-to-evict:"false"クラスタのオートスケーラー イベントの表示 | Google Kubernetes Engine (GKE) | Google Cloud
↓
最小Pod数をスケールinした値で固定する等も
■Workloads リソースPod：Workloadsリソースの最小単位ReplicaSet：Podのレプリカを作成し、指定した数のPodを維持し続けるリソースです。Deployment：ローリングアップデートやロールバックなどを実現するリソースです。DaemonSet(ReplicaSet亜種)：各ノードにPodを一つずつ配置するリソースです。StatefulSet(ReplicaSet亜種)：ステートフルなPodを作成できるリソースです。Job：Podを利用して、指定回数のみ処理を実行させるリソースです。(使い捨てPod)CronJob：Jobを管理するリソースです。Config connector：GKEでGCPリソースを調節してくれるアドオン。Podの増加減少にあたり必要なアカウントや権限やPubSub等々を自動作成や管理する。マニフェストのymlにcnrmのAPIを記載したりする（Config connector resource nameの略）Config Connectorを試してみる (zenn.dev)
■GKE関連の運用GKEクラスタ認証ローテーション30日以内になると自動ローテーションするが危険なので手動が由GKEはマイクロサービスのエンドポイントでのサービス提供かgcloud api利用が前提といえるのでこれでOK1) ローテ開始 (CPのIPとクレデンシャル)2) ノード再作成3) APIクライアントを更新 (クレデンシャル再取得)4) ローテ完了 (元IPと旧クレデンシャルの停止)クラスタ認証情報をローテーションする | Google Kubernetes Engine (GKE) | Google CloudGKEクラスタ認証ローテーションの考慮Google Kubernetes Engine のクラスタ認証情報をローテーションするまでに考えたこと - DMM insideセキュアなGKEクラスタそれなりにセキュアなGKEクラスタを構築する #GoogleCloud - Qiitaコントロールプレーンの自動アップグレード＆IPローテーション＆ノードブールの自動アップグレードで死ぬGKEシングルクラスタ構成で障害発生してサービス停止しちゃったのでマルチクラスタ構成にした話 (zenn.dev) CPの更新後はクレデンを取得しなおす必要がある、ArgoでCICDを組んでいるとクラスタに認証入りなおす必要がある
ノードが入れ替わりに時間が掛かり、時間差で問題がでることがあるので注意
(More)
Comment (0)
■23/12/8 11:16PM
竹書房 stardust
裁判で「ツッコんでもうた、ボケやのにっ」てボケるそしてデブキャラで復活、笑われるキャラっていうのが俺の見立て
＝＝＝＝＝＝＝＝＝＝
■中国共産党 世界最強の組織入党積極分子1年＞党員発展対象＞予備党員＞18歳から党員になれる党員になる事は難しい訳ではない、足切り5割位（マルクス主義、毛沢東思想、鄧小平理論） 党員がいるメリット：知識や思想のアップデートをし続けられる 教育、宣伝、リクリエーション（文化祭、運転会、カラオケ大会：愛国心と面子を愚弄しない事）、ボランティア党員9000万人(10人に1人)、大学や会社や社区に党支部50人迄 党支部の党員大会、全員参加で定足数は過半数、支部書記や委員の選挙は8割 下部から意見や要求の自己主張する＞上級党組織の承認による管理 流動党員（無職や引越）は新人類系での現象党委員会＞党基層委員会＞党総支部委員会＞党支部＞小組 党委員会も党委員会書記も党委と呼ぶ支部委員会（宣伝委員、組織委員、青年委員、婦女委員、生活委員、紀律検査委員会がコンプラ等）中央委員200人、党中央＞省レベルの党委員会党政と行政は別、地方行政と地方党のトップは別人 村民・居民委員会は行政ではないが自治や行政サービスを行い必ず有る 村民委員と党組織書記を同一人物にする取組＞一肩挑 行政には党組が設置され中央の上意下達だけが行われる 党工委は上と下を束ねる派出期間、上意下達のみ、地理や数の為 都市化されても村とよぶ、農村のイメージと違う場合も エリート専制でなく全員議論と多数決がある 複数の村で鎮、都市の社区が複数で街道（党工委を設置）取締役会監査役会を新三会、従業員代表と労組と党委員で老三会（民主管理） 労組は計画経済時代は最高意思決定機関で資本主義と少し違う、工会と呼ぶ 企業の会長より総工会主席の方が偉い 天の時や地の利も人和には敵わない＞孫子、ビジョンの共有と人の和を中共でも重視する 従業員代表大会は労組の総会一肩挑 国有企業の取締役会会長と党委書記が同一人物在中日系企業や日本領事館で中国共産党員が働いている問題、情報漏洩 仕方ない、中国のルールだし、業務時間外のみで党員教育 企業文化を作り業績上がるケースがある点を評価、党と企業の目標の融合 協調性があり成績や経歴がよい人が欲しいなら党員の可能性が高い独裁専制で愚民の意見表明や行動制限したのでなく、 各地や各職場の不満や問題を吸い上げた上でプランを立てた 不条理や窮屈もあるが、むしろ中共イメージの逆
↓共産で労働者の国と成っているが党員がそこらにおり上意下達で群衆から見ると監視社会に感じるが
中共の視点だと理想的なシステムに見える、中国なら党員になる一択？
日本だったら●●党員？高学歴で医師弁護士会計士？funnyw
■ニコニコ哲学 川上量生の胸のうち
新規プロジェクトは勇気とプライドが高い素人にやらせる。
誰がやっても失敗も多いので馬鹿がよい、走らない賢い馬は肉になる。
白紙から考え始める重要さだろうな
■米海軍で屈指の潜水艦艦長による最強組織の作り方リーダシップ：価値と潜在能力を伝え刺激する（協力を支配で操る）担当者の方がが細かいところまで詳しく知っている 権限を与えるとは支配と同じ 目標と裁量は両立するか リーダの技量が組織の業績か、メンバーの技量ではないのか疑問：活かすには命令でなく創意工夫で実務を行った方が良いのではないか結果：残留率up、組織状態better要るもの：権限だけでなく自由を与えるやる事：mtgでなく確認会（聞く方の準備や参加が必要）、命令でなく確認し許可取り
●やったこと委ねるリーダーシップ権限を与える命令を避ける命令するときは、乗員が異を唱える余地を残すやるべきことを確認する会話をする上官と部下が学びあう機会を設ける人を重視する長い目で考えるいなくなっても困らない存在を目指す訓練の回数より質を重視する正式な命令以外でも、会話を通じて情報交換するつねに好奇心を持つ意味のない手順や工程をすべて排除する監視や検査を減らす情報を公開する
●やらなかったこと命じるリーダーシップ権限を握る命令する命令するときは、 自信を持って絶対だと明言するやるべきことを説明する会議をする上官が部下を指導する機会を設ける技術を重視する目の前のことを考えるいなくなったら困る存在を目指す訓練の質より回数を重視する明瞭簡潔な言葉のみを使用し、 正式な命令以外の言葉を交わさないつねに疑いを持つ手順や工程の効率を改善する監視や検査を増やす情報を公開しない
-支配からの解放┣支配構造の遺伝子コードを見つけ出して書き換える┣態度を変えることで新しい考え方をもたらす┣早めに短く言葉を交わし、仕事の効率を高める┣ 「これから~をします」という言い方を導入し、命令に従う だけだったフォロワーを自発的に行動するリーダーに変える┣解決策を与えたい衝動を抑える┣部下を監視するシステムを排除する┗思っていることを口に出す
-優れた技能┣直前に確認する┣いつどこでも学ぶ者でいる┣説明するな、確認せよ┣同じメッセージを絶えず繰り返し発信する┗手段ではなく目標を伝える
-正しい理解┣ミスをしないだけではダメだ、優れた成果をあげよ┣信頼を構築し部下を思いやる┣行動指針を判断の基準にする┣目標を持って始める┗盲目的に従うことなく疑問を持つ姿勢を奨励する
■OODAObserve（観察）、Orient（状況判断、方向づけ）、Decide（意思決定）、Act（行動）OODAは過去の経験に捉われることなく現状にあった行動をとるためのものObserveでは先入観を持つことなく公平かつ客観的に行うことを推奨
変化を観察しスピーディな分析をし判断して進めるので生存率が高い
場当たり的、個人の判断が多い、中長期計画に適していない、仮説が弱い、ミッションバリュービジョン共有の欠如で統率問題PDCA
目標設定から始まるので、目標が明確になり、ブレずに取り組みやすい安定した環境での品質管理や一定期間かける取組などに適している 品質管理や生産管理用フレームワークの状況や前提が変わらない中で最適解を見つけるのに適している
簡易としてはPDR、Prep=準備、Do=実行、Review=復習検証PDCAは時代遅れ！？いま注目を集める「OODA（ウーダ）ループ」とは (e-sales.jp)
000961264.pdf (mhlw.go.jp)
＝＝＝＝
ティーチング：正解や解決に必要なノウハウを教えるコンサルティング：相手の問題を解決するための提案をし共に解決していくカウンセリング：悩みや不安を解決するためにサポートする
コーチング：目標達成のために行動変容を促す傾聴と質問（アドバイスしない）
人生の幸福度は「貯金の量」で決まる
幸福感が最大になる貯金額とは1億円
Comment (0)
Navi: < 5 | 6 | 7 | 8 >
-Home
-Column [133]
-Europe [9]
-Gadget [77]
-Web [137]
-Bike [4]
@/// BANGBOO BLOG ///
