問題一覧
1
AWSが提供するマネージド型のソース管理サービス。 Git の標準機能がサポートされており、Git からの移行が容易。 また、CodeCommitのリポジトリとGitHubやGitLabのリポジトリをミラーリングすることも可能。 プライベートリポジトリでありアクセストークン流出等が発生しにくい
2
GitHubのパブリックリポジトリに対してAWSクレデンシャル情報を気づかすにアップロードしてしまい、不正利用された結果、高額な利用料が請求される事件
3
リモートリポジトリの最新の履歴の取得だけを行うことができる。取得したコミットは、名前の無いブランチとして取り込まれる。このブランチはFETCH_HEADという名前でチェックアウトすることができる。
4
リモートリポジトリの履歴を取得することができる。ローカルリポジトリのmasterブランチでも履歴を進めていた場合は、両方の変更を統合する必要がある。 そのため、pullを実行するとマージが行われる。この時、競合する変更がなければ自動的にマージコミットが作られる。しかし、競合があった場合は、それを解決してから自分でコミットする必要がある
5
ソースコードをコンパイル・テストを行い、デプロイ可能なソフトウェアパッケージを作成してくれるAWSのビルドサービスのこと。ソースコードをbuildspec.ymlに従ってビルド環境の構築とテストを行う。
6
ビルド実行時に実行するコマンドを記述したYAML形式のファイルのこと。このファイルをソースコードのルートディレクトリに配置することでCodeBuildがbuildspec.ymlを読み込んで実行される。CodeCommitを使用した場合は、レポジトリのルートディレクトリに配置する。
7
ビルド環境でのパッケージのインストールにのみ使用される。ライブラリやランタイムのインストールを行う。
8
ビルド前の処理を実施する。ECRへのログインや依存関係、変数設定等を行う。
9
実際のビルド処理を定義する。テストを処理したいときはテストコマンドを定義する。
10
ビルド後の処理を実施。出力アーティファクト(出力ファイル)の作成やECRへのイメージプッシュ、ビルド通知の送信等を行う。
11
ビルドされた成果物、つまりはこれも一種のアーティファクト。ストレージにS3を利用すると思うが、実際に保存されたものの中身を開けてみると buildspec.ymlで指定されたファイル(成果物)が格納されている
12
ステージエリアにファイルを追加することができる。gitではステージエリアに、新規のファイルや編集したファイルを一度乗せた後にコミットする。ファイルをステージエリアに追加したら、git commitコマンドを使ってコミットする。その後、git pushコマンドを使用することで、ステージエリアに乗せたファイルをリモートリポジトリにプッシュ(同期)する。
13
書いたソースコードを自動でビルド、またはデプロイ、テストしてくれるサービスの一つ。一連の流れをパイプラインといい、ソースコードに対する処理をアクションという。各アクションを行う部分をステージといい、そのステージは大きく分けてソース、ビルド、デプロイの3つ構成されている。 ・ソース…S3バケットやGithub、CodeCommit内のソースコードを取得する処理。 ・ビルド…ソースで取得してソースコードをサーバなしに構築やコンパイル、テストを実行できる。 ・デプロイ…ソースコードの配置、アプリケーションやサービスの更新などを行う。 ステージを2つ以上使用して、パイプラインを構成する。また、各ステージで行ったアクション後のソースをテンプレートなどのデータの集合体アーティファクトとして、別のステージへ共有する。
14
ECSやEC2、Lambdaなど様々なサービス、またはオンプレミスインスタンスへのデプロイを実行できるサービス。 ビルドステージがなくとも、S3やGitリポジトリに保存されているアプリケーションなどをデプロイすることも可能。 使う利点としては、自動化はもちろんのことエラー時のロールバック、各環境や複数アプリケーションへの同時デプロイが可能な点があげられる
15
アプリケーション仕様ファイル。各デプロイを管理するために利用する、アプリケーションの定義ファイル。どのサービスをデプロイするか、どの定義を基にどこのインフラへリリースするかを定義している。これらの情報をソースコードとして管理して、デプロイの都度パイプラインに渡す。
16
ECSはタスクという単位で、アプリケーションを実行させる。そして、タスクの中にコンテナが1つ以上稼働する。タスクはタスク定義から作成される。タスク定義はタスクの金型的な存在です。 また、タスク定義はJSONファイル(以後taskdef.json)として運用することが一般的。
17
ビルド処理によってできた成果物
18
Apache Bench(アパッチ ベンチ)の略で、Apacheで標準に付いているWEBサーバの性能を計測するためのコマンド。基本的には-nと-cオプションを使うことになる。 -nには、Totalで発行するリクエスト数を指定。 -cには、同時接続数を指定。
19
攻撃者のより近くでブロックした方がよいという原則があるから
20
フルマネージドなWebアプリケーションファイルウォール。複数のルールを組み合わせて、トラフィックがアプリケーションに到達する方法を制御できる。SQLインジェクションやクロスサイトスクリプティング等の一般的な攻撃パターンをブロックするセキュリティルールや定義した特定のトラフィックパターンを除外するルールも自由に作成できる。
21
リクエストの検査方法を定義。特定のIPアドレスのみ許可するルール、特定のヘッダが付与されているGETリクエストのみ許可するルール等。個別の検査方法をAND条件やOR条件等で許可・拒否を定義できる。
22
ルールを集約した定義。検査するルールの優先順位を設定できる。ルールグループにはWCU(WAF Capacity Unit)と呼ばれる、いわゆる追加可能なルールの上限値を設定する必要がある。WCUはルールグループ作成時にのみ値を指定可能であり、後から変更できない。
23
ルールグループと適用するAWSリソースの紐付けの役割。ウェブACLは複数のルールグループを紐付けできるが、WCUの上限は1500となっている。Global,Region設定を間違えないように注意。
AWSのしくみと技術がわかる 5
AWSのしくみと技術がわかる 5
サラリーマンサラリーマン · 61問 · 1年前AWSのしくみと技術がわかる 5
AWSのしくみと技術がわかる 5
61問 • 1年前AWSのしくみと技術がわかる 6
AWSのしくみと技術がわかる 6
サラリーマンサラリーマン · 44問 · 1年前AWSのしくみと技術がわかる 6
AWSのしくみと技術がわかる 6
44問 • 1年前AWSのしくみと技術が分かる 7,8
AWSのしくみと技術が分かる 7,8
サラリーマンサラリーマン · 73問 · 1年前AWSのしくみと技術が分かる 7,8
AWSのしくみと技術が分かる 7,8
73問 • 1年前AWS 基礎からのネットワークサーバー 1
AWS 基礎からのネットワークサーバー 1
サラリーマンサラリーマン · 8問 · 1年前AWS 基礎からのネットワークサーバー 1
AWS 基礎からのネットワークサーバー 1
8問 • 1年前AWS 基礎からのネットワークサーバー 2,3,4
AWS 基礎からのネットワークサーバー 2,3,4
サラリーマンサラリーマン · 75問 · 1年前AWS 基礎からのネットワークサーバー 2,3,4
AWS 基礎からのネットワークサーバー 2,3,4
75問 • 1年前AWS基礎からのネットワークandサーバー構築 5,6,7,8
AWS基礎からのネットワークandサーバー構築 5,6,7,8
サラリーマンサラリーマン · 61問 · 1年前AWS基礎からのネットワークandサーバー構築 5,6,7,8
AWS基礎からのネットワークandサーバー構築 5,6,7,8
61問 • 1年前AWS基礎からのネットワークandサーバー構築 9
AWS基礎からのネットワークandサーバー構築 9
サラリーマンサラリーマン · 15問 · 1年前AWS基礎からのネットワークandサーバー構築 9
AWS基礎からのネットワークandサーバー構築 9
15問 • 1年前AWSコンテナ入門1
AWSコンテナ入門1
サラリーマンサラリーマン · 100問 · 1年前AWSコンテナ入門1
AWSコンテナ入門1
100問 • 1年前AWSコンテナ入門1 続き
AWSコンテナ入門1 続き
サラリーマンサラリーマン · 19問 · 1年前AWSコンテナ入門1 続き
AWSコンテナ入門1 続き
19問 • 1年前AWSコンテナ入門2
AWSコンテナ入門2
サラリーマンサラリーマン · 47問 · 1年前AWSコンテナ入門2
AWSコンテナ入門2
47問 • 1年前AWSコンテナ入門3
AWSコンテナ入門3
サラリーマンサラリーマン · 100問 · 1年前AWSコンテナ入門3
AWSコンテナ入門3
100問 • 1年前AWSコンテナ設計・構築3 続き
AWSコンテナ設計・構築3 続き
サラリーマンサラリーマン · 17問 · 1年前AWSコンテナ設計・構築3 続き
AWSコンテナ設計・構築3 続き
17問 • 1年前AWSコンテナ入門4
AWSコンテナ入門4
サラリーマンサラリーマン · 60問 · 1年前AWSコンテナ入門4
AWSコンテナ入門4
60問 • 1年前インフラエンジニアの教科書2 1 改訂
インフラエンジニアの教科書2 1 改訂
サラリーマンサラリーマン · 49問 · 1年前インフラエンジニアの教科書2 1 改訂
インフラエンジニアの教科書2 1 改訂
49問 • 1年前インフラエンジニアの教科書2 2 改訂
インフラエンジニアの教科書2 2 改訂
サラリーマンサラリーマン · 100問 · 1年前インフラエンジニアの教科書2 2 改訂
インフラエンジニアの教科書2 2 改訂
100問 • 1年前インフラエンジニアの教科書2 改訂続き
インフラエンジニアの教科書2 改訂続き
サラリーマンサラリーマン · 75問 · 1年前インフラエンジニアの教科書2 改訂続き
インフラエンジニアの教科書2 改訂続き
75問 • 1年前AWSの全部わかる教科書 1,2,3
AWSの全部わかる教科書 1,2,3
サラリーマンサラリーマン · 71問 · 1年前AWSの全部わかる教科書 1,2,3
AWSの全部わかる教科書 1,2,3
71問 • 1年前AWSの全部わかる教科書 4
AWSの全部わかる教科書 4
サラリーマンサラリーマン · 21問 · 1年前AWSの全部わかる教科書 4
AWSの全部わかる教科書 4
21問 • 1年前ゼロからわかるlinuxコマンド1
ゼロからわかるlinuxコマンド1
サラリーマンサラリーマン · 100問 · 1年前ゼロからわかるlinuxコマンド1
ゼロからわかるlinuxコマンド1
100問 • 1年前問題一覧
1
AWSが提供するマネージド型のソース管理サービス。 Git の標準機能がサポートされており、Git からの移行が容易。 また、CodeCommitのリポジトリとGitHubやGitLabのリポジトリをミラーリングすることも可能。 プライベートリポジトリでありアクセストークン流出等が発生しにくい
2
GitHubのパブリックリポジトリに対してAWSクレデンシャル情報を気づかすにアップロードしてしまい、不正利用された結果、高額な利用料が請求される事件
3
リモートリポジトリの最新の履歴の取得だけを行うことができる。取得したコミットは、名前の無いブランチとして取り込まれる。このブランチはFETCH_HEADという名前でチェックアウトすることができる。
4
リモートリポジトリの履歴を取得することができる。ローカルリポジトリのmasterブランチでも履歴を進めていた場合は、両方の変更を統合する必要がある。 そのため、pullを実行するとマージが行われる。この時、競合する変更がなければ自動的にマージコミットが作られる。しかし、競合があった場合は、それを解決してから自分でコミットする必要がある
5
ソースコードをコンパイル・テストを行い、デプロイ可能なソフトウェアパッケージを作成してくれるAWSのビルドサービスのこと。ソースコードをbuildspec.ymlに従ってビルド環境の構築とテストを行う。
6
ビルド実行時に実行するコマンドを記述したYAML形式のファイルのこと。このファイルをソースコードのルートディレクトリに配置することでCodeBuildがbuildspec.ymlを読み込んで実行される。CodeCommitを使用した場合は、レポジトリのルートディレクトリに配置する。
7
ビルド環境でのパッケージのインストールにのみ使用される。ライブラリやランタイムのインストールを行う。
8
ビルド前の処理を実施する。ECRへのログインや依存関係、変数設定等を行う。
9
実際のビルド処理を定義する。テストを処理したいときはテストコマンドを定義する。
10
ビルド後の処理を実施。出力アーティファクト(出力ファイル)の作成やECRへのイメージプッシュ、ビルド通知の送信等を行う。
11
ビルドされた成果物、つまりはこれも一種のアーティファクト。ストレージにS3を利用すると思うが、実際に保存されたものの中身を開けてみると buildspec.ymlで指定されたファイル(成果物)が格納されている
12
ステージエリアにファイルを追加することができる。gitではステージエリアに、新規のファイルや編集したファイルを一度乗せた後にコミットする。ファイルをステージエリアに追加したら、git commitコマンドを使ってコミットする。その後、git pushコマンドを使用することで、ステージエリアに乗せたファイルをリモートリポジトリにプッシュ(同期)する。
13
書いたソースコードを自動でビルド、またはデプロイ、テストしてくれるサービスの一つ。一連の流れをパイプラインといい、ソースコードに対する処理をアクションという。各アクションを行う部分をステージといい、そのステージは大きく分けてソース、ビルド、デプロイの3つ構成されている。 ・ソース…S3バケットやGithub、CodeCommit内のソースコードを取得する処理。 ・ビルド…ソースで取得してソースコードをサーバなしに構築やコンパイル、テストを実行できる。 ・デプロイ…ソースコードの配置、アプリケーションやサービスの更新などを行う。 ステージを2つ以上使用して、パイプラインを構成する。また、各ステージで行ったアクション後のソースをテンプレートなどのデータの集合体アーティファクトとして、別のステージへ共有する。
14
ECSやEC2、Lambdaなど様々なサービス、またはオンプレミスインスタンスへのデプロイを実行できるサービス。 ビルドステージがなくとも、S3やGitリポジトリに保存されているアプリケーションなどをデプロイすることも可能。 使う利点としては、自動化はもちろんのことエラー時のロールバック、各環境や複数アプリケーションへの同時デプロイが可能な点があげられる
15
アプリケーション仕様ファイル。各デプロイを管理するために利用する、アプリケーションの定義ファイル。どのサービスをデプロイするか、どの定義を基にどこのインフラへリリースするかを定義している。これらの情報をソースコードとして管理して、デプロイの都度パイプラインに渡す。
16
ECSはタスクという単位で、アプリケーションを実行させる。そして、タスクの中にコンテナが1つ以上稼働する。タスクはタスク定義から作成される。タスク定義はタスクの金型的な存在です。 また、タスク定義はJSONファイル(以後taskdef.json)として運用することが一般的。
17
ビルド処理によってできた成果物
18
Apache Bench(アパッチ ベンチ)の略で、Apacheで標準に付いているWEBサーバの性能を計測するためのコマンド。基本的には-nと-cオプションを使うことになる。 -nには、Totalで発行するリクエスト数を指定。 -cには、同時接続数を指定。
19
攻撃者のより近くでブロックした方がよいという原則があるから
20
フルマネージドなWebアプリケーションファイルウォール。複数のルールを組み合わせて、トラフィックがアプリケーションに到達する方法を制御できる。SQLインジェクションやクロスサイトスクリプティング等の一般的な攻撃パターンをブロックするセキュリティルールや定義した特定のトラフィックパターンを除外するルールも自由に作成できる。
21
リクエストの検査方法を定義。特定のIPアドレスのみ許可するルール、特定のヘッダが付与されているGETリクエストのみ許可するルール等。個別の検査方法をAND条件やOR条件等で許可・拒否を定義できる。
22
ルールを集約した定義。検査するルールの優先順位を設定できる。ルールグループにはWCU(WAF Capacity Unit)と呼ばれる、いわゆる追加可能なルールの上限値を設定する必要がある。WCUはルールグループ作成時にのみ値を指定可能であり、後から変更できない。
23
ルールグループと適用するAWSリソースの紐付けの役割。ウェブACLは複数のルールグループを紐付けできるが、WCUの上限は1500となっている。Global,Region設定を間違えないように注意。