EC 2、CloudFront、pm 2、NGINX(2)を備えたSSR導入ポリシー
この文章
1.購買ドメイン
2.NGINX設定
3.HTTPSの適用
前の文章にEC 2インスタンスを作成し、接続後pm 2無中継配置を行った.ただし、ポート番号は3000なので、リバースエージェントを使用してポート番号を非表示にする必要があります.Ubuntuは既存のhttpの80番ポートにリダイレクトできますが、NGINXを使用してドメインを登録し、HTTPSを設定してみます.
AWS Route 53を検索してドメインを登録し、
可能なドメインごとに価格が異なり、練習のために購入したので、一番安いドメインを選びます.
そして連絡先を記入し、誤字がないことを確認して
[連絡先詳細の確認]書き間違いがないことを確認します.
「新ドメインDNS管理」では、AWS Route 53を使用すると、管理領域が自動的に生成されると説明している.
管理領域は、すべてのサブドメインを含むドメインと簡単に言えます.example.comというドメインがある場合はdev.exampleです.comなどすべてのコンテンツを含む領域だそうです.簡単に考えてみろ53から購入したドメイン単位と考えられます.
ドメインが所有してから1年以内に登録を更新しないと期限が切れます.練習用なので更新は不要なので、ドメイン自動更新は無効になっています.
後でAmazonに電子メール認証を要求するメールが届きます.クリックして認証を行います.
これからドメイン名を登録するのに最大3日かかるそうです.のんびりと別のことをしていると、メールで登録されたというお知らせが来ます.
ドメインを登録してホスティングエリア(Hosted zone)を作成したそうです.
次に、管理領域にレコードを追加します.
購入したドメインについては、SSL/TLS証明書を取得します.これはHTTPSプロトコルをサポートするWebサイトを構築するために必要なステップです.
AWS Route 53を使用してドメインが登録されているため、
「ドメイン名」に、Route 53が管理するドメイン名を入力します.
「≪検証メソッドの選択|Select Validation Method|ldap≫」で、作成したドメイン名が実際の「≪マイドメイン|My Domain|ldap≫」であるかどうかを検証するオプションを選択します.
「ラベル」セクションをスキップし、
証明書を提供するACMは、指定されたトークン値のCNAMEレコードが存在するかどうかを決定するために、対応するドメインのネーミングサーバに要求を送信する.このため、トークン値をネームサーバのCNAMEレコードとして追加する必要がある.リファレンス
リクエスト後、証明書ページに検証待ちのステータスが表示されます.
証明書IDをクリックして「ドメイン」セクションを表示すると、追加するCNAMEレコードのリストが表示されます.ROTE 53には管理登録が行われているので,単純に
EC 2インスタンスに接続し、SSL/TLS証明書を設定するロードバランサを作成します.
発行された証明書を登録するには、
「ロード・バランサ・タイプ」で
ロードバランサ名を設定します.
ネットマップは4つともクリック.
「Listeners and routing」セクションで、
このように負荷バランサを生成すると、ターゲットグループの選択を警告します.ターゲットグループを
80ポートに設定したら、
ロード・バランシング・ステータスに戻り、作成したターゲット・グループを登録します.
Summaryで負荷バランサの設定を最終的に確認し、
[リスナー]>
以前作成したSSH/TS証明書を追加します.
最後に、登録したドメインに接続する場合は、負荷バランサの場所を識別するために、名前サーバにAレコードを追加する必要があります.
「Route 53」>「管理領域」>「作成されたドメイン」>「
レコード名が空の場合は、登録したドメイン自体を表し、何か書いた場合はサブドメインを表します.書きますwww.
「レコードタイプ」はそのままAレコードを生成します.
トラフィック・ルーティング・ターゲットを
「目標状態評価」を
[ルーティングポリシー]は
健康診断失敗エラー
1.購買ドメイン
2.NGINX設定
3.HTTPSの適用
前の文章にEC 2インスタンスを作成し、接続後pm 2無中継配置を行った.ただし、ポート番号は3000なので、リバースエージェントを使用してポート番号を非表示にする必要があります.Ubuntuは既存のhttpの80番ポートにリダイレクトできますが、NGINXを使用してドメインを登録し、HTTPSを設定してみます.
AWS Route 53にドメインを登録する
AWS Route 53を検索してドメインを登録し、
도메인 등록
を押します.可能なドメインごとに価格が異なり、練習のために購入したので、一番安いドメインを選びます.
장바구니에 추가
は、右側のカートの年間清算金額を示します.そして連絡先を記入し、誤字がないことを確認して
계속
を押します.[連絡先詳細の確認]書き間違いがないことを確認します.
「新ドメインDNS管理」では、AWS Route 53を使用すると、管理領域が自動的に生成されると説明している.
管理領域は、すべてのサブドメインを含むドメインと簡単に言えます.example.comというドメインがある場合はdev.exampleです.comなどすべてのコンテンツを含む領域だそうです.簡単に考えてみろ53から購入したドメイン単位と考えられます.
ドメインが所有してから1年以内に登録を更新しないと期限が切れます.練習用なので更新は不要なので、ドメイン自動更新は無効になっています.
주문 완료
を押して、後でAWSに予め登録されている決済手段で自動的に決済します.後でAmazonに電子メール認証を要求するメールが届きます.クリックして認証を行います.
これからドメイン名を登録するのに最大3日かかるそうです.のんびりと別のことをしていると、メールで登録されたというお知らせが来ます.
ドメインを登録してホスティングエリア(Hosted zone)を作成したそうです.
次に、管理領域にレコードを追加します.
SSL/TLS証明書の発行
公開証明書の要求
購入したドメインについては、SSL/TLS証明書を取得します.これはHTTPSプロトコルをサポートするWebサイトを構築するために必要なステップです.
AWS Route 53を使用してドメインが登録されているため、
인증서 요청
に公開証明書が要求される.퍼블릭 인증서 요청
をクリックします.「ドメイン名」に、Route 53が管理するドメイン名を入力します.
이 인증서에 다른 이름 추가
でサブドメインの証明書を適用することもできます.ex) *.ドメイン名「≪検証メソッドの選択|Select Validation Method|ldap≫」で、作成したドメイン名が実際の「≪マイドメイン|My Domain|ldap≫」であるかどうかを検証するオプションを選択します.
DNS 검증
は、ドメインの名前サーバにアクセスして、レコードを変更する権限があることを確認する方法です.「ラベル」セクションをスキップし、
요청
をクリックします.レコードの作成
証明書を提供するACMは、指定されたトークン値のCNAMEレコードが存在するかどうかを決定するために、対応するドメインのネーミングサーバに要求を送信する.このため、トークン値をネームサーバのCNAMEレコードとして追加する必要がある.リファレンス
リクエスト後、証明書ページに検証待ちのステータスが表示されます.
証明書IDをクリックして「ドメイン」セクションを表示すると、追加するCNAMEレコードのリストが表示されます.ROTE 53には管理登録が行われているので,単純に
Route 53에서 레코드 생성
を押すとCNAMEレコードが自動的に生成される.레코드 생성
をクリックします.ロードバランサ設定
EC 2インスタンスに接続し、SSL/TLS証明書を設定するロードバランサを作成します.
発行された証明書を登録するには、
EC2 - 로드밸런서
をクリックします.로드 밸런서 생성
をクリックします.「ロード・バランサ・タイプ」で
Application Load Balancer
を選択すると、HTTPプロトコルに送信された要求をHTTPSプロトコル要求に簡単にリダイレクトできます.他のタイプの負荷バランサは、端末に直接設定する必要がある不便がある.ロードバランサ名を設定します.
ネットマップは4つともクリック.
「Listeners and routing」セクションで、
Add listener
をクリックしてHTTPプロトコルを追加します.このように負荷バランサを生成すると、ターゲットグループの選択を警告します.ターゲットグループを
Create target group
で生成します.80ポートに設定したら、
Include as pending below
をクリックします.>「Create target group
」をクリックします.ロード・バランシング・ステータスに戻り、作成したターゲット・グループを登録します.
Summaryで負荷バランサの設定を最終的に確認し、
Create load balancer
をクリックして負荷バランサを生成します.[リスナー]>
규칙 보기/편집
にアクセスしてHTTPリダイレクトを設定します.수정
ボタンを押すと、HTTPを設定してHTTPSにリダイレクトします.리스너 추가
キーを押してHTTPSをプロトコルとして選択します.forward to
のDefault actionsを選択し、ターゲット・グループを指定します.以前作成したSSH/TS証明書を追加します.
Add
シースの設置を確認します.最後に、登録したドメインに接続する場合は、負荷バランサの場所を識別するために、名前サーバにAレコードを追加する必要があります.
「Route 53」>「管理領域」>「作成されたドメイン」>「
레코드 생성
」の検索レコード名が空の場合は、登録したドメイン自体を表し、何か書いた場合はサブドメインを表します.書きますwww.
「レコードタイプ」はそのままAレコードを生成します.
トラフィック・ルーティング・ターゲットを
별칭
に変更し、「アプリケーション/classic Load Barangerの別名」を選択します.ロードバランサを生成する利展(アジア太平洋(ソウル)を選択し、作成したばかりのロードバランサを指定します.「目標状態評価」を
예
とし、負荷バランサの状態を定期的に確認します.[ルーティングポリシー]は
단순 라우팅
であり、レコードを生成する.健康診断失敗エラー
EC 2 Webサーバは80番ポートで通信できないため、Apacheまたはnginxをインストールする必要があります.
NGINXのインストール
sudo apt-get install nginx -y
-yオプションは、すべての問題に対してyesを行うことを意味します.
nginxをインストールした後、EC 2の共通IPv 4 DNSアドレスに入ると、以下の画面が表示されると、接続は良好です.
接続できない場合は、「セキュリティグループ設定」でHTTPポートがすべてのユーザーを許可しているかどうかを確認します.
NGINXファイルの編集
これで、私のアドレスを入力するときにクローンの配布フォルダを開くように設定する必要があります.
まず、サーバ名が長い場合や定義が多い場合、nginxは起動せず、エラーメッセージが表示される可能性があるため、置き換えます.$ vim /etc/nginx/nginx.conf
http {
server_names_hash_bucket_size 64; # 주석해제
}
次にnginxプロファイル/etc/nginx/sites-available/default
を開きます.sudo vim /etc/nginx/sites-available/default
i
を押して入力モードに切り替え、次のような逆方向Proxy設定を行います.
sites-enabledに移動して、プロファイルの変更を適用します.cd /etc/nginx/sites-enabled/
シンボルリンクから接続プロファイルのファイルを作成します.リファレンス
シンボルリンクは、ソースを指すロールを実行します.$ ln -s /etc/nginx/sites-available/default /etc/nginx/sites-enabled/
ファイルにエラーがある場合$ ln -sf /etc/nginx/sites-available/default /etc/nginx/sites-enabled/
Permission拒否が発生した場合$ sudo ln -sf /etc/nginx/sites-available/default /etc/nginx/sites-enabled/
最後にnginx駆動時にエラーがないか確認しますsudo nginx -t
構文エラーが発生した場合は、次のコマンドを使用して具体的な確認を行います.sudo systemctl status nginx
nginx設定が変更されたら、再起動する必要があります.sudo systemctl reload nginx
502 badゲートウェイが表示されます
ここまで進むと、EC 2のパブリックアドレスに入ると次のようなエラーが発生します.
www.next-pracもありますlink接続を使用しようとすると、接続もありません.
ターゲット集団の健康状態が不健康になったことが疑われ,502エラーが発生したと考えられる.
まず、nginxのエラーログを表示するために、nginxプロファイルを少し変更しました.(を参照) $ sudo vim /etc/nginx/sites-available/default
ログチェック$ tail -f /var/log/nginx/error.log
connect() failed (111: Connection refused) while connecting to upstream
私の知識とグーグルのまとめによると、timeoutエラーを解決すればほとんど解決できます.NGINXプロファイルを開き、位置部分のバッファとタイムアウト値を変更します.location / {
proxy_connect_timeout 300s;
proxy_read_timeout 600s;
proxy_send_timeout 600s;
proxy_buffers 8 16k;
proxy_buffer_size 32k;
}
sudo nginx -t # 설정 확인 테스트
sudo systemctl reload nginx # 리로드
設定後のエラーは解決されませんでした.nginxの設定が不足しているようですが、問題は何なのか、グーグル化を続ける必要があります.
コメントサイト
[AWS]カスタムドメインを登録し、HTTPS設定SSL/TLS証明書を発行する
AWS:Route 53課金と原価計算
Reference
この問題について(EC 2、CloudFront、pm 2、NGINX(2)を備えたSSR導入ポリシー), 我々は、より多くの情報をここで見つけました
https://velog.io/@jeongs/SSR-배포-전략-with-EC2-CloudFront-pm2-NGINX-2
テキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol
sudo apt-get install nginx -y
$ vim /etc/nginx/nginx.conf
http {
server_names_hash_bucket_size 64; # 주석해제
}
sudo vim /etc/nginx/sites-available/default
cd /etc/nginx/sites-enabled/
$ ln -s /etc/nginx/sites-available/default /etc/nginx/sites-enabled/
$ ln -sf /etc/nginx/sites-available/default /etc/nginx/sites-enabled/
$ sudo ln -sf /etc/nginx/sites-available/default /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl status nginx
sudo systemctl reload nginx
ここまで進むと、EC 2のパブリックアドレスに入ると次のようなエラーが発生します.
www.next-pracもありますlink接続を使用しようとすると、接続もありません.
ターゲット集団の健康状態が不健康になったことが疑われ,502エラーが発生したと考えられる.
まず、nginxのエラーログを表示するために、nginxプロファイルを少し変更しました.(を参照)
$ sudo vim /etc/nginx/sites-available/default
ログチェック
$ tail -f /var/log/nginx/error.log
connect() failed (111: Connection refused) while connecting to upstream
私の知識とグーグルのまとめによると、timeoutエラーを解決すればほとんど解決できます.NGINXプロファイルを開き、位置部分のバッファとタイムアウト値を変更します.
location / {
proxy_connect_timeout 300s;
proxy_read_timeout 600s;
proxy_send_timeout 600s;
proxy_buffers 8 16k;
proxy_buffer_size 32k;
}
sudo nginx -t # 설정 확인 테스트
sudo systemctl reload nginx # 리로드
設定後のエラーは解決されませんでした.nginxの設定が不足しているようですが、問題は何なのか、グーグル化を続ける必要があります.コメントサイト
[AWS]カスタムドメインを登録し、HTTPS設定SSL/TLS証明書を発行する
AWS:Route 53課金と原価計算
Reference
この問題について(EC 2、CloudFront、pm 2、NGINX(2)を備えたSSR導入ポリシー), 我々は、より多くの情報をここで見つけました
https://velog.io/@jeongs/SSR-배포-전략-with-EC2-CloudFront-pm2-NGINX-2
テキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol
Reference
この問題について(EC 2、CloudFront、pm 2、NGINX(2)を備えたSSR導入ポリシー), 我々は、より多くの情報をここで見つけました https://velog.io/@jeongs/SSR-배포-전략-with-EC2-CloudFront-pm2-NGINX-2テキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol