■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)
■23/10/31 10:57PM
GCP Network Connectivity
●共有 VPC
同組織のプロジェクトのホストプロジェクト(親)のVPCをサービスプロジェクト(子)に共有●VPC ネットワーク ピアリング
異なる組織間の接続（双方のVPCでコネクションを作成する、内部IPで通信する、サブネットは重複しないこと、2ホップ制限で1:1＝3つ以上の場合は古メッシュでコネクション作成要）、k8sサービスとPod ipをVPCピアリング経由する利用法もある
●ハイブリッド サブネット Cloud VPN/Interconnect等が必要、オンプレルータとCloud RouterをBGPでつなぐ、オンプレとGCPをつなぐ
●Cloud Interconnect
DCと専用線で閉域網接続、Cloud VPNより低レイテンシ/帯域安定●Cloud VPN オンプレとIPsec VPN接続、アドレス帯の重複だめ、Cloud VPN側でBGPIP設定やIKEキー生成をしオンプレルータ側でそれらを設定する
●内部範囲
VPCで使うIPをCIDRで定義しIP範囲の使用方法を事前に決定しておく、IPが勝手に使われたりしない等ができる
●限定公開の Google アクセス（Private Google Access）
外部IPを持たないGCE等はデフォルトのインターネットゲートウェイ0.0.0.0を経由してGoogle APIにアクセスする、VPC＞Routesで見れる
●オンプレミス ホスト用の限定公開の Google アクセス CloudVPNやInterconnectを経由してオンプレから内部IPを利用してGoogleAPIにアクセス、GCP側ではCloudDNSで特定のドメインのAレコードを入れる、選択したドメインのIPアドレス範囲を静的カスタムルートでVPC内のプライベートIPからルーティングできるように設定する、オンプレにはCloudRouterからドメインのIPアドレス範囲をBGPでルーティング広報する、VPNやInterconnectがないと0.0.0.0でGoogleAPIにアクセスするがこれだとRFC1918に準拠しない199.33.153.4/30などのIPを使う必要がありルーティングが複雑化したり、オンプレを通る場合があり通信は慎重に設計をすること●Private Service Connect 「限定公開の Google アクセス」の発展版、オンプレをNATでVPCに接続、内部IPでGoogleAPIにアクセスできる、PSCエンドポイントを介して内部IPで公開できる、NATされ内部IPの公開先での重複OK
●プライベート サービス アクセス
VPCペアリングを併用してサービスプロデューサをVPCに接続し内部IPで次のようなサービスに内部IPでアクセスできるようにする（Cloud VPNまたはInterconnectを付け足せばオンプレからも可）、Cloud SQL/AlloyDB for posgre/Memorystore for Redis/Memcached/Cloud build/Apigee等の限られたもの●サーバーレス VPC アクセス
サーバレスからVPC内リソースにアクセスするためのコネクタ（通常は外部IP通信になるがコレだと内部IPでVPCにルーティングされる、/28のサブネットを指定）、例えば既存のcloud runサービスを編集しても付けられず初期構築時のみ設定できる
●外部 IP アドレスを持つ VM から API にアクセスする
IPv6をVMに設定し限定公開DNSゾーン設定をすればトラフィックはGCP内にとどまりインターネットを通りません
●CDN Interconnect
Cloud CDNもあるが他社のCDNに接続する、Akamai/Cloud flare/fastly等々
●Network Connectivity Center
ハブとなりCloudVPN/InterconnectをメッシュしGCP/オンプレ含め通信させる、Googleのバックボーンでユーザ企業の拠点間を接続できる
●ダイレクト ピアリング
GoogleのエッジNWに直接ピアリング接続を確立し高スループット化、Google workspaceやGoogleAPI用だが普通は使わずInterconnectを使う●キャリア ピアリング
ダイレクトピアリングの高度な運用が自社対応できない等でサービスプロバイダ経由でGoogle workspaceなどのGoogleアプリに品質よくアクセスする
Google CloudのVPCを徹底解説！(応用編) - G-gen Tech Blog
●トンネル系の下記は色々権限が要りそうで候補
Compute OS login/IAP-secured tunnel user/Service account user/viewer/compute.instance*
■ポートフォワードは止めないと別につないで繋いでいるつもりでも同じところに繋ぎ続ける
lsof -i 3128
ps ax | grep 3128
ps ax | sshkill [PID]
bind: Address already in use channel_setup_fwd_listener_tcpip: cannot listen to port: 3306が出たら必ず下記で調べkillするIsof-i:3306kill [該当のPID]
■IAPトンネルexport http_proxy=http://localhost:3128export https_proxy=http://localhost:3128gcloud compute start-iap-tunnel --zone asia-northeast1-a gce-proxy001 3128 --local-host-port=localhost:3128 --project=gcp-proxy-prjでコマンドを打てばIAP踏み台トンネルを通って外部に通信できる
■踏み台コマンドgcloud compute ssh --projet gcp-prj-unco --zone asia-northeast1-a gce-step-svrでSSHログインしそこからcurl等で操作する
gcloud compute ssh --project prj-step-svr --zone asia-northeast1-b dev-gcp-step001curl "http://dev.in-aaa.com/xxx"
■シークレットからPWを取りつつコマンドを打つgcloud compute ssh --project gcp-prj --zone asia-northeast1-b stp-srv --tunnel-through-iap fNL 3306:mysql.com: 3306mysql -u baka_usr -p"$(gcloud secrets versions access latest --secret mysql_pw --project=gcp-prj)" -h 127.0.0.1-P 3306 mysqlコマンドのpオプションは空白なしでPWを入れる、baka_usrはMySQLのユーザ、mysql_pwはsecret mgrに保存した名前
$()のLinuxコマンドでgcloudコマンドを入れ子。ワンライナーの形で利用ができるsecret mgrのコマンド シークレット バージョンにアクセス | Secret Manager Documentation | Google Cloudワンライナー解説（変数と$()とバッククォート /// BANGBOO BLOG /// - Linux cmd
kubectl port-forward service/cloudsql-proxy 3306:3306 -n importerとかkubectl --context gke_context_cluster_user_ns port-forward svc/cloudsql-proxy2 3306:3306とかgcloud compute ssh --project prj-step-dev --zone asia-northeast1-b dev-gcp-step001 --tunnel-through-iap --fNL 3306:dev-srv002.dev.in-aaa.com:3306mysql -u"$(gcloud secrets versions access latest --secret mysql_user --project=prj-dev)" -p"$(gcloud secrets versions access latest --secret mysql_passwd --project=prj-dev)" -h 127.0.0.1 -P 3306
■SSHトンネル
sshの基本はこれ、セキュアシェル、トンネルは特殊？SSH [オプション] [ログイン名@]接続先 [接続先で実行するcmd]
接続先に権限があること
SSHの疎通確認ssh baka@stp_srv.unco.com
設定例.ssh/config User baka Hostname step_srv ProxyCommand ssh -W %h:%p baka@step_srv.unco.com PubkeyAuthentication no PasswordAuthentication yes
※sshはPWは危険なので鍵認証のみにしたい IPアドレス元を制限や同一IPのログイン試行は拒否する仕組み等は欲しい
SSHコネクション上でトンネル作るssh step_srv -L 8080:dest.benki.com:80 とか ssh -L 8080:dest.benki.com:80 ahouser@step_srv.unco.com※ポート22でstep_srvにSSHコネクションを貼り、ローカル:8080のリクエストはdest:80に転送する↓ブラウザか新規ターミナルでcurlhttp://localhost:8080ダメなら転送設定したターミナルはstep_srvにいるのでcurl
ssh -L 8080:stg-aaa.in-aaa.com:80 user.name@stgstepcurl "http://stg-aaa.in-aaa.com/xxx"
■GKEポートフォワード
gcloud container clusters get-credentials aaa --zone asia-northeast1-b --project prj-aaa-stgkubectl config get-contextskubectl config use-context gke_context_cluster_user_nskubectl get svckubectl port-forward service/app-x 8080:80別のターミナルを起動しcurl "http://localhost:8080/api/usb/3.0/get?xxx_code=1111"
■GKEポッドの中で操作
gcloud container clusters get-credentials aaa --zone asia-northeast1-b --project prj-aaa-devkubectl get pods -n importer | grep importer (-nはnamespace)kubectl exec -it Pod名 -n importer --/bin/bash でpodのbashに入れるので、そこでpython app.py ls | grep bbb_module でモジュール名で検索python app.py run ${API_NAME} ${MODULE_NAME} --force で実行
■ヘッダー制御
curl -H 'X-YWY-IAT8UV:2pEm' 'https://dev.ex-aaa.com/xxx'
GCP、AWS、Azure 別に見るクラウド VM への攻撃経路まとめ (paloaltonetworks.jp)
＝＝＝＝＝＝＝＝＝＝＝＝＝
なぜレッドオーシャン化する前にサービスを グロースできなかったのか？ - フリマアプリ編 - (フリル)サービスを急拡大させる意思決定が遅く競合に遅れ競合出現後も経営方針を大きく変えなかった勝利条件はユーザ数で機能差ではなかったパワープレーでいかにプロモーションばら撒いて認知広げて第一想起をとるかだった先行者優位で過ごせる期間は短いスタープレイヤーの採用、手数料無料化、TVCM等PLを超えた手法があった、BS経営すべきだった成長のキャップが創業者の能力になっていた有能な人材：耳の痛いことを言ってくれる人材を経営チームに採用しても良かったCTOが開発をし、組織運営の雑務をし、採用もやっていたCEOは机の組み立てをするな。CTOはPCの購入をするな役割の変化に素早く適用し権限移譲を行い、やるべきことをやれる状況を作るあるいは必要な組織を大きくすることに注力する、例えば開発組織を大きくする戦時のCEO、皆に戦時であることを伝える、企業文化に背く意思決定も行う研究や教育等、やった方が良さそうな耳障りの良いタスクも拒否するどうやったら市場で勝てるかの戦略↓
IPOとか目指さなければConfort zoneを見つけてじっくりまったりビジネスを継続させる手もある
メルカリやPay2をみた結果論、このやり方も古いというかアレ
視力回復の音
(16) HOKKORI 📽💫🐈🐢 on X: "視力回復してください❤️🩹😹 https://t.co/Zug4pEbvys" / X (twitter.com)
Comment (0)
Navi: < 6 | 7 | 8 | 9 >
-Home
-Column [134]
-Europe [9]
-Gadget [78]
-Web [137]
-Bike [4]
@/// BANGBOO BLOG ///
