■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
■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
裁判で「ツッコんでもうた、ボケやのにっ」てボケるそしてデブキャラで復活、笑われるキャラっていうのが俺の見立て
＝＝＝＝＝＝＝＝＝＝
■ユダヤの商法 藤田田合理、契約、ケチ、疑い深い、信用、仕事お金至上金を巻き上げる/お金は奪い合い 取引額を倍々に増やし現地を耕した後に進出して直売りに変更等エグイ 日本の大企業の社員は自分の力を過大評価し世界では通用しない食を楽しむ 宗教上休みをきっちり取るし、食を楽しむやイイ女を囲ったり楽しんでる 風呂でシッカリ体を洗い清潔金持ち、女と口、好きなものより苦手なものを売った方が割り切れる ターゲットは金持ち/女性を狙う等、これは確実に見習いたい
田さん陳さん東大でGHQに通訳アルバイトし19に弟子入りし銀座のユダヤ人になった
買い切りかリピート購入/サブスクか、買い切りは長く続ける商売でなく店を畳んで違う商品をやる広告投資管理7割：年間に支払う平均金額(1年LTV)>客一人獲得に掛かる広告費上限(CPO)
■確率思考の戦略論
客引きもバンカーも運転手も世界各国で同じ雰囲気＞法則があるブランドに対する好意度：preference=ブランドイクイティ＋価格＋製品パフォーマンスプレファレンスが高いものはより高頻度で購入される＝＞シェア人はそれぞれのカテゴリのEvoked setを持ってる：エビス50黒ラベル30一番搾り20プレファレンスに基づいたエボークトセット持ち、その中のカテゴリーの購買回数分だけサイコロを振って選んでいるだけPreference好意度(ブランドイクイティ＋価格＋製品パフォーマンス)＋Awareness認知＋Distribution配荷年間購入者の全世帯に対する割合=認知率x配荷率x過去購入率xEvokedSet率x年間購入率年間売り上げ=総世帯数x1年間に買う人浸透率x平均購入回数x平均購入金額
シェア=参入順位xプレファレンスx宣伝費比率x間合い年数
どれだけ競合に比べて宣伝できているかが大きい
次回購入タイミング=平均購入回数xプレファレンス とかデータ化、確率見ていく差別化して先鋭化しても自社を選んで貰えるとは限らない 差別化でターゲットを絞ってマーケットが小さくなる危険性
ベストセラー＞観光大使/政府/首相＞人を巻き込みPRにコーラは原液販売に注力し現地生産フランチャイズにし配荷拡大した商品棚をその店/客のプレファレンスに合わせ配荷の質を改善都合が悪くなるとルールを変えてでも勝とうとする西洋人 スポーツマンシップは油断させるプロパガンダでしかないサイコパス：感情が意思決定の邪魔にならない＞選ぶストレス無しに最適判断できる ＋人心掌握（※勝ち馬しか人は選ばない、第一想起にどう入るか、高くても良い大量の広告を打つ オペを遅くしてでも行列を作る、先着サイコロ無料話題をつくる、ライトが明かる過ぎるとか目立つ店構え
＝＝＝＝
多変量解析
消費者の行動を左右する要素は様々だが、「絞り込むと本質的には3つ程度しか残らない」
最も重視すべきは「プレファレンス（相対的好意度）」。次にどれだけ知ってもらえているかという「認知」、その後、消費財であれば製品の手に取りやすさを示す「配荷」、テーマパークであればパークまでの「距離」が続く。企業が重視しがちな品質や技術力といった「パフォーマンス」の優先順位は低い。「新機能を搭載しただけでは、消費者に響かない」。相対的好意度、認知、配荷のどれかが足りないと、どんなにいい製品も埋もれてしまう。
商圏
テーマパーク業界の失敗例を調べ全国で閉園になった約50の遊園地を見ると、すべて需要を上回る投資をしていました。 需要は商圏の大きさやその人口を調べると分かります。明らかにお金を使ってはいけないところに投資をしていたのです。
可視化
思考力に強みを持つ人を「T（＝Thinking）型」、人とつながる力や伝える力が強い人を「C（＝Communication）型」、人を率いて動かす力を強みとする人を「L（＝Leadership）型」として、3つに分類し可視化。可能性の高い分野に資源を集中。
＝＝＝＝
国の大学教育の目標人材「思考力、判断力、俯瞰力、表現力の基礎の上に、幅広い教養を身につけ、高い公共性、倫理性を保持しつつ、時代の変化に合わせて積極的に社会を支え、論理的思考力を持って社会を改善していく資質」↓１）分野を超え先端の学問を学び時代の変化に合わせて積極的に社会を改善していく人材２）高度な教養と専門性がある人材３）高い実務能力がある人材
米海軍で屈指の潜水艦艦長による最強組織の作り方リーダシップ：価値と潜在能力を伝え刺激する（協力を支配で操る）担当者の方がが細かいところまで詳しく知っている 権限を与えるとは支配と同じ 目標と裁量は両立するか リーダの技量が組織の業績か、メンバーの技量ではないのか疑問：活かすには命令でなく創意工夫で実務を行った方が良いのではないか結果：残留率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]
■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等で操作する
■シークレットから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
■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
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: < 2 | 3 | 4 | 5 >
-Home
-Column [128]
-Europe [9]
-Gadget [77]
-Web [131]
-Bike [4]
@/// BANGBOO BLOG ///
