<p>CI/CDについてビルド・テスト・デプロイを自動化することってぐらいのイメージしかないので、ちゃんと調べて理解していきたいと思います。</p><h2 id="he262a6b7d1">「CI」「CD」はそれぞれ違う。</h2><p>「CI/CD」と一緒にされていることが多いと思いますが、CIとCDではそれぞれ意味が違います。</p><p>CIは、<strong>継続的インテグレーション（Continuous Integration）</strong>と呼ばれています。</p><p>CDは、<strong>継続的デプロイ（Continuous Delivery）</strong>または、<strong>継続的デプロイメント（Continuous Deployment）</strong>と呼ばれていています。</p><p>継続的とかインテグレーションとかデリバリーよくわかりにくいので、それぞれ噛み砕いて理解していきたいと思います。</p><h2 id="h0098e2417d">CIとは？</h2><p>前述の通り、<strong>継続的インテグレーション（Continuous Integration）</strong>のことです。</p><p>調べると以下のような内容で出てきます。</p><ul><li>「ソフトウェア開発のプロセスを自動化することで開発者がソースコードをコミットし、共有しているリポジトリにマージされることでビルドとテストが自動的に実行される手法である。」</li><li>「ソフトウェア開発において、ビルドやテストを自動化し、短期間で品質管理を行う手法のこと。」</li><li>「開発者が自分のコード変更を定期的にセントラルリポジトリにマージし、その後に自動化されたビルドとテストを実行する DevOps ソフトウェア開発の手法です。」</li></ul><p>継続的とかインテグレーションとかだとよくわかりませんでしたが、<strong>リポジトリへのアクションをトリガーにして自動でビルド・テストをする手法</strong>という理解としとけばわかりやすいかなと思います。</p><h2 id="h76ac2e9af2">CDとは？</h2><p>CDは、<strong>継続的デリバリー（Continuous Delivery）</strong>または<strong>継続的デプロイメント（Continuous Deployment）</strong>のことで、同じ意味で使用されることもありますが、自動化の程度を表すために区別して使用されることもあるようです。</p><h3 id="hd0438525d7">継続的デリバリーとは</h3><p>開発者によるアプリケーションへの変更に対して、バグがないか自動的にテストし、リポジトリにアップロードをすることです。</p><p><strong>テストされたソースコードを自動でアップロードしデプロイ可能な状態にする手法</strong>ということですね。</p><h3 id="h44cf006829">継続的デプロイメントとは</h3><p>開発者による変更をリポジトリから本番環境に自動的にリリースし、顧客が使用できるようにするというものです。</p><p><strong>アップロードされたソースコードを自動的に本番環境にリリースする</strong>ということですね。</p><h2 id="h33b8e2fec7">CI/CDをここまでさっくりとまとめ</h2><p><img src="https://images.microcms-assets.io/assets/b8aa8bca0ea345c69dc5acd572cdf9f1/0c22fa63d8d6493b8f1b7cdcf3b65ce9/ci-cd-flow-desktop_edited_0.png" alt=""></p><p><a href="https://www.redhat.com/ja/topics/devops/what-is-ci-cd" target="_blank" rel="noopener noreferrer"><em>CI/CD とは-継続的インテグレーション/継続的デリバリー|Red Hat</em></a><em> より引用</em></p><p>CI/CDとは、継続的インテグレーションと継続的デリバリーを繋げた作業習慣を指したり、継続的インテグレーション・継続的デリバリー・継続的デプロイメントという3つの作業習慣を繋げたものを指すこともあります。</p><p>また、継続的デリバリーが継続的デプロイメントを含んだ意味で使用されることもあります。</p><p>用語的には色々な意味合いがあるようなので、<strong>CI/CDとはビルド・テスト・デプロイの自動化を行うプロセス</strong>だと理解しておくといいかなと思います。</p><ul><li>継続的インテグレーション<ul><li><strong>リポジトリへのアクションをトリガーにして自動でビルド・テストをする手法</strong></li></ul></li><li>継続的デリバリー<ul><li><strong>テストされたソースコードを自動でアップロードしデプロイ可能な状態にする手法</strong></li></ul></li><li>継続的デプロイメント<ul><li><strong>アップロードされたソースコードを自動的に本番環境にリリースする</strong></li></ul></li></ul><h2 id="h973416292a">CI/CDの導入</h2><p>CI/CDとは何か？というところは大体分かったのですが、何を目的に導入するのか、どんなメリット・デメリットがあるのかなどを説明できる必要があると思うので、そこらへんも知っていけたらと思います。</p><h3 id="h3ab24f6f50">メリット</h3><p>まず導入するメリットにはどのようなものがあるでしょう。</p><ul><li>自動化することでビルド・テスト・デプロイのコスト削減</li><li>デプロイなどのコストが下がることで、細かいリリースを行える</li><li>コードのバグを早期に発見することができるので、影響範囲が少ないうちに修正が可能</li><li>デプロイまでの作業を自動化することで、属人化せずに済む</li><li>テストやコーディング規約のチェックを頻繁に自動的に行うことで、コードの品質がある程度保たれる</li></ul><p>など、CI/CDを導入することで得られるメリットはかなり高いかなと思いました。</p><h3 id="h7e4a670898">デメリット</h3><p>では反対に、デメリットにはどのようなものがあるのでしょうか。</p><ul><li>自動化させるためにビルドスクリプトなどを作成する必要があるので、導入コストが高くなる</li><li>継続的にリリースを行わないような場合の費用対効果が見込めない</li></ul><p>ぐらいでしょうか。</p><p>デメリットについてはこの辺りしかないように見受けられました。他にあるようでしたら教えてください。</p><h3 id="h7d1aabf4f3">どういう場合に導入をするのか</h3><p>メリット・デメリットからわかったのは、CI/CDはアジャイル開発において力を発揮するのかなと考えられます。</p><p>アジャイル開発は小さな単位でリリースを繰り返して開発を進めていきます。</p><p>そのため頻繁にデプロイを行うことになるので、CI/CDのデメリットである「導入コスト」よりメリットの恩恵を大いに受けれるかなと思います。</p><p>対して、ウォーターフォール開発ではメリットを活かせず、デメリットの方が高いのかなと考えられます。</p><p>またDevOpsにおいては、運用チームと開発チームの素早い連携が必須ですので、運用チームからの仕様変更に素早く対応してリリースを行う必要があります。</p><p>なので、DevOpsにおいてCI/CDはほぼ必須のプロセスと言えるかなと思います。</p><p>ウォーターフォール開発ではデメリットが高いと前述しましたが、CircleCIやGitHub Actionsなどのツールの発達により、最近は導入コストはそこまで高くなくなったかなと思います。</p><p>ステージング環境へのCI/CDだとか、ビルド・テストだけを行うとかで活かせると思うので、ウォーターフォール開発においてもCI/CDを導入するメリットは高そうです。</p><h2 id="ha214098e44">まとめ</h2><p>CI/CDとは何か、どういうメリットがあって導入するのかなどが理解できたかなと思います。</p><p>また、アジャイル開発・DevOpsにおいて、CI/CDはほぼ必須で導入するぐらいのものに思えました。</p><p>今後は実際にGitHub Actionsなどで自動化を実際に実装してみたいと思います。</p><h2 id="h3de35099b3">参考</h2><ul><li><a href="https://www.redhat.com/ja/topics/devops/what-is-ci-cd" target="_blank" rel="noopener noreferrer">CI/CD とは-継続的インテグレーション/継続的デリバリー|Red Hat</a></li><li><a href="https://cloudbees.techmatrix.jp/blog/struggle-story-about-ci-2/" target="_blank" rel="noopener noreferrer">【CI奮闘記】第2章：CI/CDのメリットって何？ | CloudBees|テクマトリックス</a></li><li><a href="https://www.buildinsider.net/enterprise/devops/01" target="_blank" rel="noopener noreferrer">DevOpsとは何か？ そのツールと組織文化、アジャイルとの違い - Build Insider</a></li></ul>

CI/CDとは？メリット・デメリットからちゃんと理解していく

<h2 id="h64cf7c492e">省略</h2><h3 id="h9a1a39a607">オブジェクト</h3><p>オブジェクトのプロパティに<code>?</code>を付けて宣言することで省略可能になります。</p><pre><code>type SampleObj = {
    foo: string
    bar?: string
}

let obj: SampleObj = {
    foo: 'sample',
}

console.log(obj);
// {
//   "foo": "sample"
// } 

obj = {
    foo: 'foo',
    bar: 'bar',
}

console.log(obj);
// {
//   "foo": "foo",
//   "bar": "bar"
// } </code></pre><p><code>SampleObj</code> の<code>bar</code>に<code>?</code>がついているので、省略可能となっています。</p><p>最初に定義した<code>foo</code> だけしかないオブジェクトと、<code>foo</code>と<code>bar</code> を代入したオブジェクトは同じSampleObj型になります。</p><h3 id="hd56e4caf46">関数</h3><p>関数のパラメータに<code>?</code> をつけると引数が省略可能になります。</p><pre><code>function foo(bar: number, baz?: string): void {
    console.log(`bar: ${bar}, baz: ${baz}`);
}

foo(123);           // bar: 123, baz: undefined
foo(123, 'hello');  // bar: 123, baz: hello</code></pre><p>あるいは、パラメータ宣言の後に <code>= 'hello'</code>のようにしてデフォルト値の設定ができます。</p><p>関数を実行する時に、引数を指定しなかった場合にデフォルトの値が代入されます。</p><pre><code>function foo(bar: number, baz?: string = 'hello'): void {
    console.log(`bar: ${bar}, baz: ${baz}`);
}

foo(123);           // 123, hello
foo(123, 'world');  // 123, world</code></pre><h2 id="h11f6d98e0f">undefinedをチェックする</h2><p>JavaScriptでは存在しないプロパティにアクセスするとundefinedが返却されます。</p><p>省略したプロパティや引数の型は<code>string | undefined</code> のようにUnion型（ユニオン型）となります。</p><p>（stringなのは省略しているのがstring型のため）</p><p><code>?</code>で省略したプロパティや関数の引数を使用すると、undefinedの可能性があるのでエラーとなってしまいます。</p><p>そのため省略したプロパティや引数はundefinedのチェックをして使用する必要があります。</p><pre><code>type SampleObj = {
    foo: string
    bar?: string
}

function func(obj: SampleObj): void {
    // const bar = obj.bar.toUpperCase
    // Error: Object is possibly 'undefined'.
    // toUpperCaseはstringのメソッドなので、undefinedの可能性があるとエラーとなる


    // 三項演算子でundefinedかをチェックする
    const bar = obj.bar != null ? obj.bar.toUpperCase : '';

    // Null合体演算子でも可能
    // const bar = obj.bar ?? '';

    // Optional Chainingでも可能
    // const bar = obj.bar?.toUpperCase

    console.log(bar)
}

let obj: SampleObj = {
    foo: 'sample',
}

func(obj) // ""

obj = {
    foo: 'foo',
    bar: 'bar',
}

func(obj) // "BAR"</code></pre><h2 id="h27759c2fca">?で省略したのと「string | undefined」は同じ意味ではない</h2><p>前述したように<code>?</code>で省略すると<code>string | undefined</code> というようにUnion型に変換されます。</p><p>しかし、<code>?</code>を使用せずに <code>string | undefined</code> と自分で定義した場合は省略できず、同じ意味にはなりません。</p><p><code>?</code>を使わない場合は、たとえundefinedが許されていても、プロパティや関数の引数として宣言しないといけないのです。</p><pre><code>type SampleObj = {
    foo: string
    bar?: string | undefined
}

let obj: SampleObj = {
    foo: 'sample',
}
// Error
// let obj: SampleObj
// Property 'bar' is missing in type '{ foo: string; }' but required in type 'SampleObj'.
// : 'bar' is declared here.

// 以下のようにundefinedと宣言するとエラーにならない
// let obj: SampleObj = {
//     foo: 'sample',
//     bar: undefined
// }


function foo(bar: number, baz: string | undefined): void {
    console.log(`bar: ${bar}, baz: ${baz}`);
}

foo(123)
// Error
// Expected 2 arguments, but got 1.(2554)
// : An argument for 'baz' was not provided.

// 以下のようにundefinedと宣言するとエラーにならない
// foo(123, undefined)</code></pre><h2 id="h3de35099b3">参考</h2><ul><li><a href="https://qiita.com/uhyo/items/e2fdef2d3236b9bfe74a#-%E7%9C%81%E7%95%A5%E5%8F%AF%E8%83%BD%E3%81%AA%E3%83%97%E3%83%AD%E3%83%91%E3%83%86%E3%82%A3" target="_blank" rel="noopener noreferrer">TypeScriptの型入門 - Qiita</a></li><li><a href="https://typescript-jp.gitbook.io/deep-dive/type-system/functions" target="_blank" rel="noopener noreferrer">関数の型 - TypeScript Deep Dive 日本語版</a></li></ul><h2 id="h691f93fa66">おすすめ参考書</h2><iframe frameborder="0" allowfullscreen="true" src="//rcm-fe.amazon-adsystem.com/e/cm?lt1=_blank&amp;bc1=000000&amp;IS2=1&amp;bg1=FFFFFF&amp;fc1=000000&amp;lc1=0000FF&amp;t=ykms1230e-22&amp;language=ja_JP&amp;o=9&amp;p=8&amp;l=as4&amp;m=amazon&amp;f=ifr&amp;ref=as_ss_li_til&amp;asins=4873119049&amp;linkId=14a865142bfcc32bb4b97d9ec257ead6"></iframe><iframe frameborder="0" allowfullscreen="true" src="//rcm-fe.amazon-adsystem.com/e/cm?lt1=_blank&amp;bc1=000000&amp;IS2=1&amp;bg1=FFFFFF&amp;fc1=000000&amp;lc1=0000FF&amp;t=ykms1230e-22&amp;language=ja_JP&amp;o=9&amp;p=8&amp;l=as4&amp;m=amazon&amp;f=ifr&amp;ref=as_ss_li_til&amp;asins=4297127474&amp;linkId=63d98f7462a4c7e3d3352c15bcb2b52e"></iframe><iframe frameborder="0" allowfullscreen="true" src="//rcm-fe.amazon-adsystem.com/e/cm?lt1=_blank&amp;bc1=000000&amp;IS2=1&amp;bg1=FFFFFF&amp;fc1=000000&amp;lc1=0000FF&amp;t=ykms1230e-22&amp;language=ja_JP&amp;o=9&amp;p=8&amp;l=as4&amp;m=amazon&amp;f=ifr&amp;ref=as_ss_li_til&amp;asins=B07T477V6G&amp;linkId=30581815f0afab804fcd699a25e5927b"></iframe><p><br></p>

【TypeScript】?の省略と「string | undefined」のユニオン型を一緒にしない

<h2 id="h8d027c8ed3">はじめに</h2><p>この記事は <a href="https://qiita.com/advent-calendar/2021/miraito-inc" target="_blank" rel="noopener noreferrer">ミライトデザイン Advent Calendar 2021</a>&nbsp;の 23日目の記事となっています。</p><p>前回は「<a href="https://qiita.com/tkek321/items/5d7714d7170bbf379c11" target="_blank" rel="noopener noreferrer">docker-laravel の Docker 構成をちゃんと理解する【Dockerfile 編 - PHP】</a>」という記事を書いてくれた <a href="https://qiita.com/tkek321" target="_blank" rel="noopener noreferrer">takuma</a> でした。</p><p><a href="https://qiita.com/tkek321/items/9c0c5cec1dc349c67f5f" target="_blank" rel="noopener noreferrer">docker-compose 編</a>もあるので、そっちも見てみてください。</p><p>さて、今回の記事は、IP制限を<strong>GAE（Google App Engine）</strong>で実現したいユースケースがあったのですが、GAEは自動的にIPv6に対応するそうで、半固定のIPv6に対しては固定IPで制限ができないという事象がありました。</p><p>色々方法はあると思いますが、今回は<strong>Serverless NEG</strong>を使用し<strong>ロードバランサ経由</strong>でGAEにアクセスすることで、IP制限の実現ができたのでそちらの紹介をします。</p><h2 id="h0cc85de624">NEGとは？</h2><p>そもそも<strong>NEG</strong>というのは「<strong>Network Endpoint Group</strong>」の略です。</p><p>名前の通り<strong>複数のネットワークエンドポイントをまとめたもの</strong>となっていて、ロードバランサのエンドポイントとして指定が可能となっています。</p><p>NEGにはいくつか種類があり、今回のケースでは<strong>Serverless NEG</strong>というものを使用します。</p><p>以下の画像は<strong>GKE（Google Kubernetes Engine）</strong>での画像ですが、イメージしやすいと思ったので持ってきました。</p><p><img src="https://images.microcms-assets.io/assets/b8aa8bca0ea345c69dc5acd572cdf9f1/12a584277d6b4d9aa844f7d541e9acae/9477d544-network_endpoint_group_ingress.gif" alt=""></p><p><a href="https://cloud.google.com/blog/products/containers-kubernetes/container-native-load-balancing-on-gke-now-generally-available" target="_blank" rel="noopener noreferrer"><em>Container-native load balancing on GKE now generally available | Google Cloud Blog</em></a><em> より引用</em></p><p>従来のGKEのロードバランサは <strong>iptables</strong> で再度負荷分散をするという2段階ロードバランシングだったのを、NEGを使用することで直説負荷分散できるといった内容を紹介してくれています。</p><p>NEGとは何かという方にはイメージしやすいのではないでしょうか。</p><p><strong>【NEGの種類】</strong></p><ul><li>Zonal NEG</li><li>Internet NEG</li><li>Serverless NEG</li><li>Hybrid connectivity NEG</li><li>Private Service Connect NEG</li></ul><p><em>公式：</em><a href="https://cloud.google.com/load-balancing/docs/negs" target="_blank" rel="noopener noreferrer"><em>Network endpoint groups overview&nbsp;|&nbsp;Load Balancing&nbsp;|&nbsp;Google Cloud</em></a></p><h2 id="h2099926ac9">Serverless NEGとは？</h2><p><strong>Serverless NEG</strong>というのは<strong>サーバーレスサービスに対して使用できるNEGです</strong>。</p><p>NEGは今まで<strong>GCE（Google Compute Engine）</strong>や<strong>GKE</strong>にしか使用できなかったようですが、Serverless NEGの登場により「<strong>App Engine</strong>」「<strong>Cloud Functions</strong>」「<strong>Cloud Run</strong>」のサーバーレスサービスでも使用ができるようになりました。</p><p>そのため、ロードバランサのエンドポイントにサーバーレスサービスを指定し、ロードバランサでIPv4を指定することでGAEにはIPv4でのアクセスとなり、本来やりたかった固定IPの制限が可能になるということです。</p><h2 id="h9c9feddf28">環境構築手順</h2><p>では実際に環境を作ってみましょう。</p><p>大きく手順としては以下の通りです。</p><ol><li> GAEをデプロイする</li><li>静的IPアドレスを取得する</li><li>Serverless NEGを作成する</li><li>バックエンドサービスを作成する</li><li>ロードバランサを設定する</li></ol><h3 id="haae876fc0d">GAEをデプロイする</h3><p>GAEのアプリケーションがデプロイされている上でIP制限をかけたいというユースケースのため、ここではGAEのデプロイ詳細は省略します。</p><p>Laravelの例ですが、IPの確認をするためにエンドポイントに以下のアクションを追加しておくとGAEへのリクエストIPの確認ができます。</p><pre><code>public function ip(Request $request): array
{
    return [
        'ip' =&gt; $request-&gt;ip(),
        'ips' =&gt; $request-&gt;ips(),
        'client_ip' =&gt; $request-&gt;getClientIp(),
        'client_ips' =&gt; $request-&gt;getClientIps(),
        'X-Appengine-User-Ip' =&gt; $request-&gt;header('X-Appengine-User-Ip'),
    ];
}</code></pre><p>GAEでIPを確認する場合は <strong><code>X-Appengine-User-Ip</code></strong> ヘッダーから取得して確認します。</p><p><em>公式：</em><a href="https://cloud.google.com/appengine/docs/standard/php7/reference/request-response-headers" target="_blank" rel="noopener noreferrer"><em>Request Headers and Responses&nbsp;|&nbsp;App Engine standard environment for PHP 7 docs&nbsp;|&nbsp;Google Cloud</em></a></p><p><strong>静的IPアドレスの作成</strong></p><p>ロードバランサのエンドポイントに使用するため静的IPアドレスを作成しておきます。</p><pre><code>gcloud compute addresses create [IPアドレス論理名] \
    --ip-version=IPV4 \
    --global</code></pre><p>以下のコマンドで予約されている IPv4 アドレスを控えときましょう。</p><pre><code>gcloud compute addresses describe [IPアドレス論理名] \
    --format="get(address)" \
    --global</code></pre><p>GUI上でも作成されていることが確認できます</p><p><img src="https://images.microcms-assets.io/assets/b8aa8bca0ea345c69dc5acd572cdf9f1/99b136d2d9d440ebb24de8b13835deef/2cb33639-7c9db82fb0b5ae39ae1df050f3e5f5ab.png" alt=""></p><h2 id="h7ef56048ff"><strong>Serverless NEGの作成</strong></h2><p>GAE用のServerless NEGを作成します。</p><p>なお、リージョンについてはGAEと同じリージョンにする必要があります。</p><pre><code>gcloud compute network-endpoint-groups create [ServerlessNEG論理名] \
    --region=[リージョン名] \
    --network-endpoint-type=serverless  \
    --app-engine-app \
		--app-engine-service=default</code></pre><p>作成されたことを以下のコマンドで確認します。</p><pre><code>gcloud beta compute network-endpoint-groups list
NAME                           LOCATION         ENDPOINT_TYPE  SIZE
[ServerlessNEG論理名]           [リージョン名]       SERVERLESS     0</code></pre><p>GUI上でも作成されていることが確認できます。</p><p><img src="https://images.microcms-assets.io/assets/b8aa8bca0ea345c69dc5acd572cdf9f1/0cd120b05f1f46c480cf956632fd9cf5/ba074361-95ef77e03b14f34a4aff7d10006d7a5d.png" alt=""></p><h2 id="hf16abf8dd9"><strong>バックエンドサービスの作成</strong></h2><p>バックエンドサービスを作成し、バックエンドとして先ほど作成した Serverless NEG を追加します。</p><pre><code>gcloud compute backend-services create [バックエンドサービス論理名] \
    --global

NAME                            BACKENDS  PROTOCOL
[バックエンドサービス論理名]                     HTTP</code></pre><h3 id="he2e96d39f9"><strong>バックエンドサービスにServerless NEGを追加</strong></h3><pre><code>gcloud compute backend-services add-backend [バックエンドサービス論理名] \
    --global \
    --network-endpoint-group=[ServerlessNEG論理名] \
    --network-endpoint-group-region=[リージョン名]</code></pre><p>バックエンドサービスが作成され、Serverless NEGが追加されているかを以下のコマンドで確認しましょう。</p><pre><code>gcloud beta compute backend-services list
NAME                      BACKENDS                                                PROTOCOL  LOAD_BALANCING_SCHEME  HEALTH_CHECKS
[バックエンドサービス論理名]     [リージョン名]/networkEndpointGroups/[ServerlessNEG論理名]   HTTP      EXTERNAL</code></pre><p>GUI上でも確認ができます。</p><p><img src="https://images.microcms-assets.io/assets/b8aa8bca0ea345c69dc5acd572cdf9f1/a5eef1e0235845df80a5759c1750a877/25a2641c-5761141b83609fcbe3717dcd01782349.png" alt=""></p><h2 id="h2ee46426ec">ロードバランサーの設定</h2><p>まずは受信リクエストをバックエンドサービスにルーティングするためのURLマップを作成します。</p><pre><code>gcloud compute url-maps create [ロードバランサ論理名] \
    --default-service [バックエンドサービス論理名]

NAME                 DEFAULT_SERVICE
[ロードバランサ論理名]    backendServices/[バックエンドサービス論理名]</code></pre><h3 id="hc5df7c3780"><strong>ターゲットhttpプロキシを作成しロードバランサに追加</strong></h3><p>URL マップにリクエストをルーティングするターゲット HTTPS プロキシを作成します。</p><p>HTTP ロードバランサの場合、HTTP ターゲット プロキシを作成します</p><pre><code>gcloud compute target-http-proxies create [ターゲットhttpプロキシ論理名] \
    --url-map=[ロードバランサ論理名]

NAME                        URL_MAP
[ターゲットhttpプロキシ論理名]    [ロードバランサ論理名]</code></pre><h3 id="h409fa3a176"><strong>フロントエンド(forwarding rule)をロードバランサに追加</strong></h3><pre><code>gcloud compute forwarding-rules create [フロントエンド論理名] \
    --address=[控えていたIPアドレスを指定] \
    --target-http-proxy=[ターゲットhttpプロキシ論理名] \
    --global \
    --ports=80</code></pre><h3 id="h70eb6e0625"><strong>ロードバランサ・フロントエンドの確認</strong></h3><p>以下のコマンドで作成したものを確認しましょう。</p><pre><code>$ gcloud compute forwarding-rules list
NAME                REGION     IP_ADDRESS   IP_PROTOCOL  TARGET
[フロントエンド論理名]   [IPアドレス]               TCP          [ターゲットhttpプロキシ論理名]</code></pre><p>GUIでも確認</p><p><img src="https://images.microcms-assets.io/assets/b8aa8bca0ea345c69dc5acd572cdf9f1/515fe9714a9541d79d016fee15531042/3c2c69a6-c5293e12fb50f283800dfe1689841eab.png" alt=""></p><p><img src="https://images.microcms-assets.io/assets/b8aa8bca0ea345c69dc5acd572cdf9f1/4bfa675cae084d24888b66a55a656b51/4e9f68cd-73a0c19a662a2af93a62f7ff53f9a291.png" alt=""></p><h2 id="hf8cc2bd493">ロードバランサにリクエストしてみる</h2><p>作成したロードバランサにリクエストをしてみましょう。</p><p>取得したIPアドレスをURLに入力してアクセスするとデプロイしたアプリケーションの画面が表示されます。</p><p>自分の場合はLaravelのアプリケーションをデプロイしたので、Webcomeページが表示されます。</p><p><img src="https://images.microcms-assets.io/assets/b8aa8bca0ea345c69dc5acd572cdf9f1/93bef43238694e36be25e2d377fb14e1/80be4671-38cce6f7903788d858c70d01ec7f0a86.png" alt=""></p><h2 id="hd7c089008c">固定IPでアクセスできるかを確認してみる</h2><p>もともとデプロイしていたアプリケーションのIPを確認するとIPv6でアクセスされていることが確認できます。</p><p><img src="https://images.microcms-assets.io/assets/b8aa8bca0ea345c69dc5acd572cdf9f1/c83acee94ef044b8b19d03a1d0c71bf4/57a082c5-dcfc50d380b605b3d553394ac544bcf8.png" alt=""></p><p>次に作成したロードバランサにアクセスしてIPv4でアクセスされていることを確認します。</p><p>GAEへアクセスされているIPを調べるために追加したエンドポイントを叩いて <strong><code>X-Appengine-User-Ip</code></strong> の値を確認すると、固定IPとなっているかと思います。</p><p><img src="https://images.microcms-assets.io/assets/b8aa8bca0ea345c69dc5acd572cdf9f1/c83acee94ef044b8b19d03a1d0c71bf4/57a082c5-dcfc50d380b605b3d553394ac544bcf8.png" alt=""></p><h2 id="h9be0c3393d">おわりに</h2><p>クライアントがIPv6でアクセスしてきたとしても、GAEにはIPv4でアクセスできていることが確認できたと思います。</p><p>GAEでは自動でIPv6に対応するため、IPv4の固定IPでIP制限が必要な場合は今回紹介した方法で試してみてください。</p><p>この後DNSの設定やSSLの設定をすることで実用化できると思いますが、今回は省略します。</p><p>できれば余裕があるときに追記していけたらと思います。</p><h2 id="h3de35099b3">参考</h2><ul><li><a href="https://www.publickey1.jp/blog/10/google_app_engineipv6.html" target="_blank" rel="noopener noreferrer">Google App Engineのアプリは自動的にIPv6対応に － Publickey</a></li><li><a href="https://medium.com/google-cloud-jp/neg-%E3%81%A8%E3%81%AF%E4%BD%95%E3%81%8B-cc1e2bbc979e" target="_blank" rel="noopener noreferrer">NEG とは何か. はじめに | by Yuki Furuyama | google-cloud-jp | Medium</a></li><li><a href="https://medium.com/google-cloud-jp/serverless-neg-%E3%81%A7%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E9%96%8B%E7%99%BA%E3%82%92%E3%82%88%E3%82%8A%E6%9F%94%E8%BB%9F%E3%81%AB-4f9cebd2780f" target="_blank" rel="noopener noreferrer">Google Cloud Serverless NEG | google-cloud-jp</a></li><li><a href="https://cloud.google.com/load-balancing/docs/negs/setting-up-serverless-negs" target="_blank" rel="noopener noreferrer">サーバーレス NEG の設定&nbsp;|&nbsp;負荷分散&nbsp;|&nbsp;Google Cloud</a></li><li><a href="https://christina04.hatenablog.com/entry/network-endpoint-group" target="_blank" rel="noopener noreferrer">NEG(Network Endpoint Group)を使った負荷分散 - Carpe Diem</a></li><li><a href="https://www.apps-gcp.com/serverless-neg-and-gae/" target="_blank" rel="noopener noreferrer">Serverless NEG + GAE を試してみる | apps-gcp.com</a></li><li><a href="https://qiita.com/g-yama/items/baf6ae05a8c83a77598f" target="_blank" rel="noopener noreferrer">Serverless NEG(Network Endpoint Group)を設定しGAEと連携してみた - Qiita</a></li></ul>

Serverless NEGを使用して、GAEにIPv4の固定IPアドレスでIP制限をする

<h2 id="hdb41525ba7">ブログテンプレートから作成されました🎉</h2><p>ブログテンプレートからAPIを作成しました。</p><p>おつかれさまでした🎉</p><p><br></p><h2 id="hf45076424a">APIプレビューを試そう🚀</h2><p>最初に「APIプレビュー」をしてみましょう。</p><p>入稿したコンテンツはAPI経由で取得し、Viewに繋ぎ込みます。</p><p>APIプレビューでは実際のAPIレスポンスを確認でき、あなたの開発を加速させます。</p><p><br></p><p>👇まずはここをクリックします。</p><p><img src="https://images.microcms-assets.io/assets/b8aa8bca0ea345c69dc5acd572cdf9f1/4d3625fa43e54938bd533eabba5c9d8f/blog-template-description1.png" alt=""></p><p><br></p><p>APIプレビュー画面が開いたら、<strong>「取得」</strong>ボタンでリクエストを試してみましょう。</p><p><img src="https://images.microcms-assets.io/assets/b8aa8bca0ea345c69dc5acd572cdf9f1/a2344494ecd04c4d932c598f197857a3/blog-template-description2.png" alt=""></p><p><br></p><p>この記事の内容がAPIで取得できていることがわかります。</p><p><img src="https://images.microcms-assets.io/assets/b8aa8bca0ea345c69dc5acd572cdf9f1/564768e3d1804135bfd42bc543e118e9/blog-template-description3.png" alt=""></p><h2 id="h4c50a0f1e5"><br>次にやること🏃‍♂️</h2><p>APIプレビューで確認したレスポンスを参考に、あなた自身のWebサイトを構築しましょう。</p><p>microCMSはAPIでコンテンツを取得するため、お好きな言語・フレームワークで画面を構築できます。</p><p><br></p><ul><li><a href="https://document.microcms.io/tutorial/javascript/javascript-top" target="_blank" rel="noopener noreferrer">JavaScript SDK</a></li><li><a href="https://document.microcms.io/tutorial/nuxt/nuxt-top" target="_blank" rel="noopener noreferrer">Nuxt SDK</a></li><li><a href="https://document.microcms.io/tutorial/gatsby/gatsby-top" target="_blank" rel="noopener noreferrer">Gatsby SDK</a></li></ul><p><br></p><p>その他に<a href="https://microcms.io/features/sdk" target="_blank" rel="noopener noreferrer">サーバーサイドSDK（PHP / Go / Ruby）やモバイルSDK（iOS / Android）</a>もございます。</p><p><br></p><p>お困りなことや疑問点などございましたらお気軽にご連絡ください。</p><p><br></p><p>サポート窓口：<a href="mailto:support@microcms.io" target="_blank" rel="noopener noreferrer">support@microcms.io</a></p><p>よくある質問：<a href="https://help.microcms.io/ja/knowledge" target="_blank" rel="noopener noreferrer">https://help.microcms.io/ja/knowledge</a></p>

Posts

CI/CDとは？メリット・デメリットからちゃんと理解していく

【TypeScript】?の省略と「string | undefined」のユニオン型を一緒にしない

Serverless NEGを使用して、GAEにIPv4の固定IPアドレスでIP制限をする

（サンプル）まずはこの記事を開きましょう

（サンプル）まずはこの記事を開きましょう

（サンプル）まずはこの記事を開きましょう

（サンプル）まずはこの記事を開きましょう

（サンプル）まずはこの記事を開きましょう

（サンプル）まずはこの記事を開きましょう

（サンプル）まずはこの記事を開きましょう