■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*
■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等で操作する
＝＝＝＝＝＝＝＝＝＝＝＝＝
なぜレッドオーシャン化する前にサービスを グロースできなかったのか？ - フリマアプリ編 - (フリル)サービスを急拡大させる意思決定が遅く競合に遅れ競合出現後も経営方針を大きく変えなかった勝利条件はユーザ数で機能差ではなかったパワープレーでいかにプロモーションばら撒いて認知広げて第一想起をとるかだった先行者優位で過ごせる期間は短いスタープレイヤーの採用、手数料無料化、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)
■23/2/11 1:46AM
HSTS/CORS/CSPOAuth/OpenID/SAML/XSS/CSRF/JSOP/SSO/SSL/SVG/JWT
=========================
2023-02-11
フロントエンド開発のためのセキュリティ入門 - Speaker Deck
HTTPとHTTPSが混ざっているwebサイトはHSTS(http strict transport securityヘッダ)でHTTPS強制できる JSのfetch,xhr/iframe/canvas/WebStorage,IndexedDBでクロスオリジンは危険 Access-Control-Allow-OriginレスポンスヘッダでCORS(cross origin resource sharing)許可を判定できる CSP(Content-Security-Policy）レスポンスヘッダあるはmetaタグで許可するJSを判定できる
SVG
ChatGPTにSVGでお絵描きさせる｜temoki / Tomoki Kobayashi (note.com)
タグで図が書ける
JWT (JSON WEB TOKEN?)
JWTセキュリティ入門 - Speaker Deck
=========================
2022-04-06
SAML SSOのログイン状態を保持する認証プロバイダー(IdP)を使い各アプリ(ServiceProvider)でSSOを実現する SSOの仕組みにはエージェント方式、リバースプロキシ方式、代理認証方式など ユーザはWebサービスにアクセス WebサービスからSSO認証プロバイダーサーバにSAML認証要求をPostする SSO認証プロバイダーサーバでSAML認証を解析、ユーザに認証を転送 ユーザはそれでWebサービスにログインする
SAMLはログイン時にユーザー情報をチェック、OAuthはユーザーの情報を登録OAuthはアプリケーションを連動させるAPIで有効なアクセストークンかを見る アクセストークンには「いつ」「どこで」「なんのために」作られたのか分からないOpenIDはIDトークンを使い「いつ」「どこで」「なんのために」作られたのか分かる
OAuth 2.0、OpenID Connect、SAMLを比較OAuth 2.0：新しいアプリケーションに登録して、新しい連絡先をFacebookや携帯電話の連絡先から自動的に取得することに同意した場合は、おそらくOAuth 2.0が使われています。この標準は、安全な委任アクセスを提供します。つまり、ユーザーが認証情報を共有しなくても、アプリケーションがユーザーに代わってアクションを起こしたり、サーバーからリソースにアクセスしたりすることができます。これは、アイデンティティプロバイダー（IdP）がユーザーの承認を得て、サードパーティのアプリケーションにトークンを発行できるようにすることで実現されます。
OpenID Connect：Googleを使ってYouTubeなどのアプリケーションにサインインしたり、Facebookを使ってオンラインショッピングのカートにログインしたりする場合に使用されるのが、この認証オプションです。OpenID Connectは、組織がユーザーを認証するために使用するオープンスタンダードです。IdPはこれを利用して、ユーザーがIdPにサインインした後、他のWebサイトやアプリにアクセスする際に、ログインしたりサインイン情報を共有したりする必要がないようにします。
SAML：SAML認証は、多くの場合に仕事環境で使用されます。たとえば、企業のイントラネットやIdPにログインした後、Salesforce、Box、Workdayなどの多数の追加サービスに、認証情報を再入力せずにアクセスできるようになります。SAMLは、IdPとサービスプロバイダーの間で認証・認可データを交換するためのXMLベースの標準で、ユーザーのアイデンティティとアクセス許可を検証し、サービスへのアクセスの許可/拒否を決定します。OAuth、OpenID Connect、SAMLの違いとは？ | Okta
Oath: idpがトークンを発行、Webサイト間でユーザを認識し3rdからでも個人情報を使えるようになるOpenID(OIDC): idpとJWT(トークン)で認証するOauth系のSSO、Oauthの拡張でログインが3rdからもできるようになるSAML: idpで各アプリやAD間をXMLメッセージにより認証管理しSSOを実現 OpenIDとSAMLが同じような機能 SAMLはユーザ固有の傾向で大企業SSOが多い、OpenIDはアプリ固有の傾向でWebサイトやモバイルアプリが多い SAMLよりOIDCの方が新しくSPAやスマホと親和性が高い SaaSとしてOpenIDはOktaのidp、SAMLはPingFederateのidpがメジャー
=========================
2016-01-03
■XSS対策、CSRF対策、脆弱性チェック
情報処理推進機構にチェックリスト有
https://www.ipa.go.jp/security/vuln/websecurity.htmlXSS対策
フォーム送信後の確認画面ではHTMLエスケープ等でサニタイズされた内容の結果を表示
DBへのクエリについてはプレースホルダやエスケープ等でSQLインジェクションを防ぐ
target="_blank"はXSSになるので危ない、rel="noopener noreferrer"を付ける
https://b.hatena.ne.jp/entry/s/webtan.impress.co.jp/e/2020/03/13/35510
https://laboradian.com/test-window-opener/
CSRF対策
前ページでhidden値を入れる
他
クッキーに具体的なものは入れない、CookieにHttpOnly属性、HTTPS通信ではsecure属性
エラーメッセージを表示しない
不要なファイルは削除
XMLの外部実態参照は禁止、サーバ上でコードが実行される
→libxml_disable_entity_loader(true)で止める、xmlをアップロードさせない/使用しない、JSON使う
PDFからHTTPリクエストが発行される
→PDFをアップロードさせない
------
//SQLインジェクション対策
\ " ' を\エスケープ
$sql = "UPDATE users SET name='.mysql_real_escape_string($name).'WHERE id='.mysql_real_escape_string ($id).'";
//クロスサイトスクリプティング対策
表示時には<>&"をメタ文字へ変換
echo htmlspecialchars($_GET['username'], ENT_QUOTES);
$ent = htmlentities($ent, ENT_QUOTES, "UTF-8"); //100個の文字を変換
//クロスサイトスクリプティング対策
別サイトからのポストを弾く
refferを送信しないリクエストもある（別サイトのリファラを弾き、nullもしくは適切ページからを許可する）
セッションIDで判断する
//DOS対策
2重ポスト
IPと日付で2重ポストを防ぐ（同IPのポストがx秒以内を弾く）
========
■JSONP
scriptタグを使用してクロスドメインなデータを取得する仕組みのことである。
HTMLのscriptタグ、JavaScript（関数）、JSONを組み合わせて実現される
GoogleAnalyticsのクッキーは1stパーティでサイト側がオーナでありGoogleがオーナーではない
サイト側のJSでクッキーが作成されるようなっている
クッキーが送信される相手はどこか？が重要でGoogleでなくサイト側に送信される
アクセス履歴は別途データをGoogleに送信しており、クッキーはセッション管理に使用される
■SSO
色々な方法がある、SAMLや、サイトにエージェントを組み込み＋SSO認証サーバ等
ロジックを確認しないと詳しくは分からない
=========
■SSL【図解】よく分かるデジタル証明書(SSL証明書)の仕組み 〜https通信フロー,発行手順,CSR,自己署名(オレオレ)証明書,ルート証明書,中間証明書の必要性や扱いについて〜 | SEの道標 (nesuke.com)デジタル証明書の仕組み (infraexpert.com)
認証局とは | GMOグローバルサインカレッジ (globalsign.com)
サーバでRSA秘密鍵とCSRを生成し公開鍵を認証局(CA)登録CAはサーバに証明書(署名)を発行＝＝＝＝クライアントが接続要求サーバが証明書(署名とRSA公開鍵を含む)を送るクライアントが証明書を検証(
どっち？
１）署名をルート証明書のチェーン(RSA公開鍵)で複合化しドメインを確認
該当のルート証明書(RSA公開鍵)がブラウザにないと該当CAに要求？
CRLやOCSPで失効について問合せができるようだがRSA公開鍵の要求は出来なさそう （ルート証明書はブラウザにある結局オレオレ証明書に違いない：厳密な審査の上で組込まれている）
２）クライアントが公開鍵をサーバに送りRSA秘密鍵で暗号化し送り返すとクライアントが複合化してRSA秘密鍵が正しい事を確認
)クライアントが共通鍵（セッションキー）を生成し公開鍵で暗号化し送るサーバが秘密鍵で共通鍵を複合
以降共通鍵暗号で通信 ※ホンマか？？
＝＝＝＝
ホスト（ドメイン）を持って接続要求をし、暗号化通信後にパスやクエリパラメータを送るので、詳細は暗号化され守られている
Comment (0)
■22/7/24 3:46AM
Docker
どこでビルドしてもデプロイしてもImmutableインフラ（不変の）なので変更したい場合はDockerfileの方を変えるコンテナはOS上のDockerEngine上に配置する（コンテナは複数配置できる、Dockerfileさえあれば再現可）
DockerfileでなくてもDockerイメージでもいいが、Dockerは可搬性をもたらすのである なおVMはOSをもシミュレート
１部: はじめに｜実践 Docker - ソフトウェアエンジニアの「Docker よくわからない」を終わりにする本 (zenn.dev)
２部: Dockerfile の基礎｜実践 Docker - ソフトウェアエンジニアの「Docker よくわからない」を終わりにする本 (zenn.dev)
３部: 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 --versionwho 誰がログインしているか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つを１つのイメージで建てられる（以前はdocker runだった）docker container run --name コンテナ名001 -d -p 8081:80 イメージ名httpd
docker container run --name コンテナ名002 -d -p 8082:80 イメージ名httpddocker container run --name コンテナ名003 -d -p 8083:80 イメージ名httpd
■仮想NW
コンテナ間をつなぐ（ネットワークタグ名で紐づける感じ）
１）ブリッジネットワーク（デフォルト 同一の Docker Engine 上のコンテナ が互いに通信をする場合に利用する デフォルト： 全てのコンテナ間をリンクする操作が必要 コンテナ間の通信は IP アドレスで ●(コレ使う)ブリッジネットワークを定義し作成： 相互通信は同じネットワークを割り当てるだけ コンテナ間でDNS解決される ネットワークでコンテナは隔離され隔離度が上がる２）オーバーレイネットワーク 異なる 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/
■ボリュームのマウント
データをコンテナ内に置くとコンテナが消えるとデータも消えてしまう
永続化１）ボリュームマウント：DockerEngine上
永続化２）バインドマウント：OS上
永続化３）一時メモリマウント：（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 3appコンテナがdbに疎通できるかping
■アプリ
/// BANGBOO BLOG /// - GCP script 下の方に記載あり
■Dockerfile
ビルドしてイメージを作成
FROM イメージ名
COPY コピー元パス コピー先パス
RUN Linuxのコマンド
ENTRYPOINT イメージを実行するときのコマンド
CMD コンテナ起動時に実行する規定のコマンドを指定
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つの方法がある
１）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
２）docker run に引数を付ける→ソフトウェア(apache)が動いていない状態になり改めてdocker startが必要
docker exec -it コンテナ名httpd001 /bin/bash
apt install mysql-server など対話でコンテナにインスコできる
exit 抜ける
■Docker composedocker runコマンドの集合体、コンテナ等作って消すだけ（k8sはコンテナ等を管理する）
以前はdocker-composeコマンドで別ツールだったが今は統合済み
フォルダに1つだけdocker-compose.yml
基本はdocker runを実行せずにdocker composeしたい
手順は、１）Docker run方法で一応の検討>２）docker-compose.ymlの記述>３）docker composeコマンドの実行
docker run~~に対するdocker-compose.ymlとdocker composeコマンド の対比
１）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
↓２） 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-pwnetworks: net001volumes: 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.
３）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 等で実際の名前を確認して操作する
■コンテナ デバッグ
３部: デバッグノウハウ ( 番外編 )｜実践 Docker - ソフトウェアエンジニアの「Docker よくわからない」を終わりにする本 (zenn.dev)
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
基本はLinuxの機能を使っているnamespaceで分離しファイル構造、ユーザーID、グループID、コマンド、ライブラリなど諸々をラップしコンテナ化し(単一の)プロセスとして動く↓
Dockerがやっている仕事は少ない
区切ってコンテナ
それら仮想ネットワークで繋ぐ
ボリュームの永続化
Dockerfileでイメージからイメージを作成Docker composeでdocker runを記述docker execでコンテナを操作etc.
Comment (0)
Navi: 1 | 2 | 3 | 4 >
-Home
-Column [126]
-Europe [9]
-Gadget [76]
-Web [122]
-Bike [4]
@/// BANGBOO BLOG ///