46 KiB
DevOps ハンドブック
このガイドは、インフラストラクチャスタックとプラットフォームをどのように維持するかを理解するのに役立ちます。 このガイドで、すべての操作について詳しく説明しているわけではありませんが、システムを理解する上での参考になります。
ご意見やご質問があれば、どうぞご連絡ください。喜んでご説明いたします。
フライトマニュアル - コードデプロイ
このリポジトリは、継続的に構築され、テストされ、インフラストラクチャの個別のセット (サーバー、データベース、CDNなど) にデプロイされます。
これには3つのステップが含まれます。
- 新規変更 (修正および機能変更の両方を含む) は、プルリクエストによりプライマリ開発ブランチ (
main
) にマージされます。 - これらの変更は、一連の自動テストで実行されます。
- テストに合格すると、インフラストラクチャ上でのデプロイメントに対して変更をリリースします(または必要に応じて更新します)。
コードベースのビルド - Git ブランチのデプロイメントへのマッピング
通常、main
(デフォルトの開発ブランチ) は、prod-staging
ブランチに 1 日 1 回マージされ、分離されたインフラストラクチャにリリースされます。
これは開発者とボランティアのコントリビューター用の中間リリースです。 「ステージング」または「ベータ」リリースとも呼ばれます。
それは freeCodeCamp.org
のライブプロダクション環境と同じで、データベース、サーバー、Web プロキシなどの別々のセットを使用しています。 この分離により、freeCodeCamp.org の main プラットフォームの正規ユーザーに影響を与えることなく、「本番」のようなシナリオで継続的な開発と機能をテストすることができます。
開発者チーム @freeCodeCamp/dev-team
が、ステージングプラットフォームでの変更に満足したら、これらの変更は数日ごとに prod-current
ブランチに移されます。
これが freeCodeCamp.org で本番プラットフォームに変更を加えた最終リリースです。
変更のテスト - 統合テストとユーザー承認テスト
私たちは、コードの品質を確認するために、様々なレベルの統合と受け入れテストを採用しています。 すべてのテストは、GitHub Actions CI や Azure Pipelines のようなソフトウェアにより実行されます。
私たちは、チャレンジソリューション、Server API、クライアントユーザーインターフェースをテストするための単体テストを行っています。 これらは、異なるコンポーネント間の統合をテストするのに役立ちます。
[!NOTE] また、メールの更新や API やサードパーティサービスへの呼び出しなど、現実世界のシナリオを再現するのに役立つエンドユーザーテストを作成中です。
これらのテストを組み合わせることで、問題が繰り返されるのを防ぎ、別のバグや機能の作業中にバグが発生しないようにします。
変更のデプロイ - 変更をサーバーにプッシュする
開発サーバーと本番サーバーに変更をプッシュする継続的デリバリーソフトウェアを設定しています。
保護されたリリースブランチに変更がプッシュされると、そのブランチに対してビルドパイプラインが自動的にトリガーされます。 ビルドパイプラインは、アーティファクトを構築し、後で使用するためにコールドストレージに保管する責任があります。
実行が正常に完了すると、ビルドパイプラインは対応するリリースパイプラインをトリガーします。 リリースパイプラインは、ビルドアーティファクトを収集し、それらをサーバーに移動し、稼働させる責任があります。
ビルドとリリースのステータスは こちら からご確認いただけます。
ビルドをトリガー・テスト・デプロイする
現時点では、開発チームのメンバーのみが本番ブランチにプッシュできます。 production-*
ブランチへの変更は、upstream
への早送りマージによってのみ可能です。
[!NOTE] 今後、アクセス管理と透明性を向上させるために、プルリクエストを介してこのフローを改善します。
ステージングアプリケーションに変更をプッシュする
-
リモートを正しく構成します。
git remote -v
結果:
origin git@github.com:raisedadead/freeCodeCamp.git (fetch) origin git@github.com:raisedadead/freeCodeCamp.git (push) upstream git@github.com:freeCodeCamp/freeCodeCamp.git (fetch) upstream git@github.com:freeCodeCamp/freeCodeCamp.git (push)
-
main
ブランチが初期状態であり、アップストリームと同期していることを確認してください。git checkout main git fetch --all --prune git reset --hard upstream/main
-
GitHub CI がアップストリームの
main
ブランチを渡していることを確認してください。継続的インテグレーション テストは、
main
ブランチに関して、緑色であり PASSING でなければなりません。main
ブランチコードを表示する際、コミットハッシュの横にある緑色のチェックマークをクリックします。GitHub Actionsでステータスを確認する (スクリーンショット)
![GitHub Actions でビルドステータスを確認する](https://raw.githubusercontent.com/freeCodeCamp/freeCodeCamp/main/docs/images/devops/github-actions.png)これに失敗した場合は、停止してエラーの確認をします。
-
リポジトリをローカルにビルドできることを確認します。
npm run clean-and-develop
-
早送りマージにより、変更を
main
からprod-staging
に移行します。git checkout prod-staging git merge main git push upstream
[!NOTE] 強制的にプッシュすることはできません。履歴を書き直した場合、これらのコマンドはエラーになります。
エラーになったとしたら、誤った操作をしたかもしれませんので、やり直します。
上記手順では、prod-staging
ブランチのビルドパイプラインで自動的に実行がトリガーされます。 ビルドが完了すると、アーティファクトは .zip
ファイルとしてコールドストレージで保存され、後で取り出され使用されます。
接続されたビルドパイプラインから新たなアーティファクトが利用可能になると、リリースパイプラインが自動的にトリガーされます。 ステージングプラットフォームでは、このプロセスに手動での承認は含まれません。また、アーティファクトは クライアント CDN および API サーバーにプッシュされます。
本番アプリケーションに変更をプッシュする
プロセスはほとんどステージングプラットフォームと同じですが、いくつかの追加のチェックが行われます。 これは、何百人ものユーザーが常に使用している freeCodeCamp.org 上で何も壊さないようにするためです。
すべてがステージングプラットフォームで動作していることを確認しない限り、これらのコマンドを実行しないでください。 先に進む前に、ステージング上のテストを回避またはスキップしないでください。 |
---|
-
prod-staging
ブランチが初期状態であり、アップストリームと同期していることを確認してください。git checkout prod-staging git fetch --all --prune git reset --hard upstream/prod-staging
-
早送りマージにより、変更を
prod-staging
からprod-current
に移行します。git checkout prod-current git merge prod-staging git push upstream
[!NOTE] 強制的にプッシュすることはできません。履歴を書き直した場合、これらのコマンドはエラーになります。
エラーになったとしたら、誤った操作をしたかもしれませんので、やり直します。
上記手順では、prod-current
ブランチのビルドパイプラインで自動的に実行がトリガーされます。 ビルドアーティファクトの準備が完了すると、リリースパイプラインで実行がトリガーされます。
スタッフアクションの追加手順
リリースの実行がトリガーされると、開発者スタッフチームのメンバーは自動的に手動介入メールを受け取ります。 彼らはリリース実行を 承認、または 拒否 することができます。
変更がうまく動作し、ステージングプラットフォームでテストされている場合は、承認することができます。 承認は、自動的に拒否される前に、リリースがトリガーされてから4時間以内に行われる必要があります。 拒否された実行が拒否された場合、スタッフは手動でリリース実行を再トリガーするか、リリースの次のサイクルを待つことになります。
スタッフ用:
ビルドの実行が完了したら、直接リンクについて E メールを確認するか、リリースダッシュボードにアクセス してください。 |
---|
スタッフがリリースを承認すると、パイプラインは freeCodeCamp.org の本番用 CDN および API サーバーにその変更を反映させます。
ビルド、テスト、デプロイのステータス
ここでは、コードベースの現在のテスト、ビルド、およびデプロイの状況を示します。
ブランチ | 単体テスト | 統合テスト | ビルド & デプロイ |
---|---|---|---|
main |
- | ||
prod-staging |
Azure Pipelines | ||
prod-current |
Azure Pipelines | ||
prod-next (試験的、予定) |
- | - | - |
早期アクセスとベータテスト
皆さんがこれらのリリースを "パブリックベータテスト" モードでテストし、プラットフォームの今後の機能に早期アクセスできるようにします。 これらの機能 / 変更は、ネクスト、ベータ、ステージング などと呼ばれます。
フィードバックや Issue 報告を通じた貢献は、復元力、一貫性 および 安定性 のある freeCodeCamp.org
本番プラットフォームを構築するのに役立ちます。
見つけたバグの報告や、freeCodeCamp.orgをより良くする支援に感謝します。 素晴らしい皆さんです!
プラットフォームの今後のバージョンを特定する
現在、パブリックベータテストバージョンは次の場所で利用できます。
アプリケーション | 言語 | URL |
---|---|---|
学習 | 英語 | https://www.freecodecamp.dev |
スペイン語 | https://www.freecodecamp.dev/espanol | |
中国語 | https://chinese.freecodecamp.dev | |
ニュース | 英語 | https://www.freecodecamp.dev/news |
フォーラム | 英語 | https://forum.freecodecamp.dev |
中国語 | https://chinese.freecodecamp.dev/forum | |
API | - | https://api.freecodecamp.dev |
[!NOTE] ドメイン名は
freeCodeCamp.org
とは異なります。 これは、検索エンジンのインデックス作成を防止し、プラットフォームの通常ユーザーの混乱を避けるための、意図的なものです。上記リストは、提供するアプリケーションを包括したものではありません。 また、リソースを節約するために、すべての言語バリエーションがステージングにデプロイされるわけではありません。
プラットフォームの現在のバージョンを特定する
プラットフォームの現在のバージョンは freeCodeCamp.org
で常に利用できます。
開発者チームは、リリース変更時に、prod-staging
ブランチから prod-current
への変更をマージします。 トップコミットは、サイト上で表示されるもののはずです。
ステータスセクションにあるビルド & デプロイログにアクセスして、デプロイされた正確なバージョンを確認できます。 またはコントリビューターチャットルームで問い合わせてください。
既知の制限
プラットフォームのベータ版を使用する場合、いくつかの既知の制限とトレードオフがあります。
-
これらのベータプラットフォーム上のデータ / 個人的な進捗は、保存されたり本番環境に移行されることはありません。
ベータ版のユーザーは本番とは異なるアカウントを持つことになります。 ベータ版は本番と物理的に分離されたデータベースを使用します。 これにより、偶発的なデータ損失や変更を防ぐことができます。 開発チームは、必要に応じてこのベータ版のデータベースを削除する可能性があります。
-
ベータ版プラットフォームの稼働時間と信頼性については保証はありません。
デプロイは頻繁に行われ、時には非常に速いペースで 1 日に複数回行われることになります。 その結果、ベータ版において、不測のダウンタイムが発生したり機能が壊れることがあります。
-
修正を確認する手段として、このサイトに一般ユーザーを送らないでください。
ベータサイトは、ローカルの開発とテストを強化するためのものでしたし、今もそうです。 それはこれから起こることを約束するものではありませんが、取り組まれていることを垣間見るものです。
-
サインインページが本番環境とは異なる場合があります。
Auth0 上で freeCodeCamp.dev にはテストテナントを使用しているため、カスタムドメインを設定することはできません。 そのため、すべてのリダイレクトコールバックとログインページが
https://freecodecamp-dev.auth0.com/
のようなデフォルトドメインに表示されます。 これが機能に影響を与えることはありませんし、本番環境に近いものです。
Issue の報告とフィードバック
ディスカッションやバグ報告をする場合、新しい Issue を開いてください。
ご質問があれば、dev[at]freecodecamp.org
にメールをご送信ください。 セキュリティ脆弱性は、公開トラッカーやフォーラムではなく、security[at]freecodecamp.org
に報告する必要があります。
フライトマニュアル - サーバーメンテナンス
[!WARNING]
- ガイドは、freeCodeCamp スタッフのみ に適用されます。
- インストラクションは包括的なものではありませんので、ご注意ください。
スタッフの一員として、Azure、Digital Ocean などのクラウドサービスプロバイダーへのアクセスが許可されている可能性があります。
仮想マシン (VM) で作業するために使用できる便利なコマンドをいくつか紹介します。例えばメンテナンスの更新や一般的なハウスキーピングの実行です。
VM のリストを取得する
[!NOTE] 既に VM へ SSH アクセスできるかもしれませんが、クラウドポータルへのアクセスが許可されていない限り VMを一覧表示することはできません。
Azure
Azure CLI のインストール az
: https://docs.microsoft.com/en-us/cli/azure/install-azure-cli
(一回のみ)
homebrew
で macOS にインストールします。
brew install azure-cli
(一回のみ) ログインします。
az login
VM 名と IP アドレスのリストを取得します。
az vm list-ip-addresses --output table
Digital Ocean
Digital Ocean CLI doctl
のインストール: https://github.com/digitalocean/doctl#installing-doctl
(一回のみ)
homebrew
で macOS にインストールします。
brew install doctl
(一回のみ) ログインします。
認証とコンテキストの切り替え: https://github.com/digitalocean/doctl#authenticating-with-digitalocean
doctl auth init
VM 名と IP アドレスのリストを取得します。
doctl compute droplet list --format "ID,Name,PublicIPv4"
新しいリソースをスピンする
私たちは IaC 設定の作成に取り組んでいます。そして、その作業中は Azure ポータルまたは Azure CLI を使用して、新しい仮想マシンやその他のリソースをスピンさせることができます。
[!TIP] スピニングリソースの選択に関係なく、docker のインストールや SSH キーの追加など基本的なプロビジョニングを行うのに役立つ 便利な cloud-init 設定ファイル がいくつかあります。
VM を最新に保つ
アップデートとアップグレードを行うことで、VM を最新の状態に保つ必要があります。 これにより、仮想マシンが最新のセキュリティ修正でパッチされるようになります。
[!WARNING] これらのコマンドを実行する前に下記を実行します。
- VM が完全にプロビジョニングされており、インストール後の手順が実行されていないことを確認してください。
- アプリケーションを既に提供している VM 上で、パッケージを更新する場合は、アプリが停止 / 保存されていることを確認してください。 パッケージ更新により、ネットワーク帯域幅や、メモリ、CPU の使用率が急増し、 実行中のアプリケーションが停止します。
パッケージ情報を更新します。
sudo apt update
インストール済みパッケージをアップグレードします。
sudo apt upgrade -y
未使用のパッケージをクリーンアップします。
sudo apt autoremove -y
Web サーバーでの作業 (プロキシ)
Web サーバーのために、負荷分散 (Azure Load Balancer) インスタンスを実行しています。 これらのサーバーは NGINX を実行しています。NGINX は、独自インフラストラクチャで実行される様々なアプリケーションから freeCodeCamp.org へと、トラフィックを中継するリバースプロキシとして使用されます。
NGINX 設定は このリポジトリ で確認できます。
最初のインストール
コードを使用して VM をプロビジョニング
-
NGINX をインストールし、リポジトリから設定します。
sudo su cd /var/www/html git clone https://github.com/freeCodeCamp/error-pages cd /etc/ rm -rf nginx git clone https://github.com/freeCodeCamp/nginx-config nginx cd /etc/nginx
-
Cloudflare のオリジン証明書とアップストリームアプリケーション設定をインストールします。
安全なストレージから Cloudflare のオリジン証明書を取得し、 必要な場所にインストールします。
または
既存の証明書を移動させます。
# Local scp -r username@source-server-public-ip:/etc/nginx/ssl ./ scp -pr ./ssl username@target-server-public-ip:/tmp/ # Remote rm -rf ./ssl mv /tmp/ssl ./
アップストリーム設定を更新します。
vi configs/upstreams.conf
ソース / オリジンアプリケーションの IP アドレスを追加 / 更新します。
-
ネットワーキングとファイアウォールを設定します。
必要に応じて、イングレスオリジンアドレスに Azure ファイアウォールと
ufw
を設定します。 -
VM をロードバランサーバックエンドプールに追加します。
必要に応じて、ロードバランサーにルールを設定し追加します。 バランサーバックエンドプールをロードするために、VM を追加する必要があるかもしれません。
ログとモニタリング
-
以下のコマンドを使用して NGINX サービスのステータスを確認します。
sudo systemctl status nginx
-
サーバーのログとモニタリングは以下で行います。
現行の基本的なモニタリングダッシュボードは、NGINX Amplify (https://amplify.nginx.com) です。 監視向上のため、より細かいメトリックに取り組んでいます。
インスタンスの更新 (メンテナンス)
NGINX インスタンスへの設定変更は、GitHub 上でメンテナンスされています。これらは、以下のように各インスタンスにデプロイされる必要があります。
- SSH でインスタンスに接続し、sudo と入力します。
sudo su
- 最新の設定コードを取得します。
cd /etc/nginx
git fetch --all --prune
git reset --hard origin/main
- 設定 with Signals をテストして再度読み込みます。
nginx -t
nginx -s reload
API インスタンスでの作業
- ノードバイナリのビルドツール (
node-gyp
) をインストールします。
sudo apt install build-essential
最初のインストール
コードを使用して VM をプロビジョニング
-
ノード LTS をインストールします。
-
npm
を更新して PM2 をインストールし、logrotate
を設定して起動します。npm i -g npm@8 npm i -g pm2 pm2 install pm2-logrotate pm2 startup
-
freeCodeCamp をクローンし、env とキーをセットアップします。
git clone https://github.com/freeCodeCamp/freeCodeCamp.git cd freeCodeCamp git checkout prod-current # or any other branch to be deployed
-
セキュア認証情報ストレージから
.env
を作成します。 -
セキュア認証ストレージから
google-credentials.json
を作成します。 -
依存関係をインストールします。
npm ci
-
サーバーを構築します。
npm run create:config && npm run build:curriculum && npm run build:server
-
インスタンスを開始します。
cd api-server pm2 reload ecosystem.config.js
ログとモニタリング
pm2 logs
pm2 monit
インスタンスの更新 (メンテナンス)
コードの変更は、適宜 API インスタンスにデプロイする必要があります。 ローリング更新または手動更新により実行できます。 依存関係を変更したり、環境変数を追加したりする場合は、後者が必須です。
[!ATTENTION] 自動パイプラインは、分単位で依存関係の更新を処理していません。 デプロイパイプラインが実行される前に、手動で更新する必要があります。
1. 手動更新 - 依存関係や env 変数の更新に使用します。
- すべてのインスタンスを停止します。
pm2 stop all
- 依存関係をインストールします。
npm ci
- サーバーを構築します。
npm run create:config && npm run build:curriculum && npm run build:server
- インスタンスを開始します。
pm2 start all --update-env && pm2 logs
2. ローリング更新 - コードの論理的な変更に使用されます。
pm2 reload all --update-env && pm2 logs
[!NOTE] パイプライン経由で、コードやロジックの更新をロールリング処理しています。 これらのコマンドを実行する必要はありません。 ドキュメント用として、ここに記載されているだけです。
クライアントインスタンスでの作業
- ノードバイナリのビルドツール (
node-gyp
) をインストールします。
sudo apt install build-essential
最初のインストール
コードを使用して VM をプロビジョニング
-
ノード LTS をインストールします。
-
npm
を更新して PM2 をインストールし、logrotate
を設定して起動します。npm i -g npm@8 npm i -g pm2 npm install -g serve pm2 install pm2-logrotate pm2 startup
-
クライアントの設定をクローンし、envとキーをセットアップします。
git clone https://github.com/freeCodeCamp/client-config.git client cd client
Web クライアントのプレイスホルダーインスタンスを開始します。これらは、Azure パイプラインのアーティファクトで更新されます。
Todo: この設定は S3 または Azure Blob ストレージに移動する必要があります。
echo "serve -c ../../serve.json www -p 50505" >> client-start-primary.sh chmod +x client-start-primary.sh pm2 delete client-primary pm2 start ./client-start-primary.sh --name client-primary echo "serve -c ../../serve.json www -p 52525" >> client-start-secondary.sh chmod +x client-start-secondary.sh pm2 delete client-secondary pm2 start ./client-start-secondary.sh --name client-secondary
ログとモニタリング
pm2 logs
pm2 monit
インスタンスの更新 (メンテナンス)
コードの変更は、適宜 API インスタンスにデプロイする必要があります。 ローリング更新または手動更新により実行できます。 依存関係を変更したり、環境変数を追加したりする場合は、後者が必須です。
[!ATTENTION] 自動パイプラインは、分単位で依存関係の更新を処理していません。 デプロイパイプラインが実行される前に、手動で更新する必要があります。
1. 手動更新 - 依存関係、env 変数の更新に使用します。
-
すべてのインスタンスを停止します。
pm2 stop all
-
依存関係をインストールまたは更新します。
-
インスタンスを開始します。
pm2 start all --update-env && pm2 logs
2. ローリング更新 - コードの論理的な変更に使用されます。
pm2 reload all --update-env && pm2 logs
[!NOTE] パイプライン経由で、コードやロジックの更新をロールリング処理しています。 これらのコマンドを実行する必要はありません。 ドキュメント用として、ここに記載されているだけです。
チャットサーバーでの作業
チャットサーバーは、Rocket.Chat ドキュメントで推奨されている HA 構成で利用可能です。 そのために使用する docker-compose
ファイルは、こちらで入手可能 です。
Rocket.Chat クラスタの前で、負荷分散型 (Azure ロードバランサー) の冗長 NGINX インスタンスを提供します。 NGINX 設定ファイルは、こちらで入手可能 です。
最初のインストール
コードを使用して VM をプロビジョニング
NGINX クラスタ:
-
NGINX をインストールし、リポジトリから設定します。
sudo su cd /var/www/html git clone https://github.com/freeCodeCamp/error-pages cd /etc/ rm -rf nginx git clone https://github.com/freeCodeCamp/chat-nginx-config nginx cd /etc/nginx
-
Cloudflare のオリジン証明書とアップストリームアプリケーション設定をインストールします。
安全なストレージから Cloudflare のオリジン証明書を取得し、 必要な場所にインストールします。
または
既存の証明書を移動させます。
# Local scp -r username@source-server-public-ip:/etc/nginx/ssl ./ scp -pr ./ssl username@target-server-public-ip:/tmp/ # Remote rm -rf ./ssl mv /tmp/ssl ./
アップストリーム設定を更新します。
vi configs/upstreams.conf
ソース / オリジンアプリケーションの IP アドレスを追加 / 更新します。
-
ネットワーキングとファイアウォールを設定します。
必要に応じて、イングレスオリジンアドレスに Azure ファイアウォールと
ufw
を設定します。 -
VM をロードバランサーバックエンドプールに追加します。
必要に応じて、ロードバランサーにルールを設定し追加します。 バランサーバックエンドプールをロードするために、VM を追加する必要があるかもしれません。
Docker クラスタ:
-
Docker をインストールし、リポジトリから設定します。
git clone https://github.com/freeCodeCamp/chat-config.git chat cd chat
-
必要な環境変数とインスタンス IP アドレスを設定します。
-
Rocket-chat サーバーを実行します。
docker-compose config docker-compose up -d
ログとモニタリング
-
以下のコマンドを使用して NGINX サービスのステータスを確認します。
sudo systemctl status nginx
-
docker インスタンスの実行ステータスを確認します。
docker ps
インスタンスの更新 (メンテナンス)
NGINX クラスタ:
NGINX インスタンスへの設定変更は、GitHub 上でメンテナンスされています。これらは、以下のように各インスタンスにデプロイされる必要があります。
-
SSH でインスタンスに接続し、sudo と入力します。
sudo su
-
最新の設定コードを取得します。
cd /etc/nginx git fetch --all --prune git reset --hard origin/main
-
設定をテストし、シグナルを使用してリロードします。
nginx -t nginx -s reload
Docker クラスタ:
-
インスタンスに SSH で接続し、チャット設定パスに移動します。
cd ~/chat
-
最新の設定コードを取得します。
git fetch --all --prune git reset --hard origin/main
-
Rocket.Chat の最新 docker イメージをプルダウンします。
docker-compose pull
-
実行中のインスタンスを更新します。
docker-compose up -d
-
インスタンスが起動していることを検証します。
docker ps
-
不要なリソースをクリーンアップします。
docker system prune --volumes
出力:
WARNING! This will remove: - all stopped containers - all networks not used by at least one container - all volumes not used by at least one container - all dangling images - all dangling build cache Are you sure you want to continue? [y/N] y
使用していないものをすべて削除するには、「はい」(y) を選択しします。 これにより、停止されたコンテナ、コンテナによって使用されていないネットワークとボリューム、および宙ぶらりんイメージ (dangling image) とビルドキャッシュを削除します。
Contributor ツールでの作業
更新をデプロイする
(Digital Ocean 上でホストされている) VM に ssh で接続します。
cd tools
git pull origin master
npm ci
npm run build
pm2 restart contribute-app
VM での Node.js のバージョン更新
現在インストールされている node と npm のバージョンをリストアップします。
nvm -v
node -v
npm -v
nvm ls
最新の Node.js LTS をインストールし、グローバルパッケージを再インストールします。
nvm install --lts --reinstall-packages-from=default
インストールされたパッケージを確認します。
npm ls -g --depth=0
エイリアス default
Node.js バージョンを現在の LTS に設定します (最新のメジャーバージョンに固定します)。
nvm alias default 16
(オプション) 旧バージョンをアンインストールします。
nvm uninstall <version>
[!ATTENTION] クライアントアプリケーションでは、
pm2 resurrect
を使用して、Node.js バージョン間でシェルスクリプトを復元することはできません。 ゼロからプロセスをデプロイします。 docker ベースの設定に移行すると、より良くなるはずです。プロセスに PM2 を使用する場合は、アプリケーションを起動し、再起動時に自動リカバリを行うためのプロセスリストを保存する必要があります。
unstartup
コマンドでアンインストールの手順 / コマンドを取得し、出力を使用して systemctl サービスを削除します。
pm2 unstartup
startup
コマンドでインストールの手順 / コマンドを取得し、出力を使用して systemctl サービスを追加します。
pm2 startup
以下は、PM2 からリストへのクイックコマンド、保存されたプロセスの復元などです。
pm2 ls
pm2 resurrect
pm2 save
pm2 logs
Azure Pipeline エージェントのインストールと更新
https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux?view=azure-devops を参照し、手順に従ってエージェントを停止、削除、再インストールします。 一般的には、ここに記載されている手順に従います。
https://dev.azure.com/freeCodeCamp-org/_usersSettings/tokens から入手できる PAT が必要です。
デプロイターゲットへのエージェントのインストール
Azure Devops に移動し、必要な デプロイグループ でエージェントをゼロから登録します。
[!NOTE] スクリプトをホームディレクトリで実行し、他の
azagent
ディレクトリが存在しないことを確認します。
エージェントの更新
現在、エージェントを更新するには、エージェントを削除して再設定する必要があります。 これは、PATH
の値や他のシステム環境変数を正しく取り出すために必要です。 デプロイターゲット VM 上で、Node.js を更新する場合は、以下を実行する必要があります。
-
移動して、サービスのステータスを確認します。
cd ~/azagent sudo ./svc.sh status
-
サービスを停止します。
sudo ./svc.sh stop
-
サービスをアンインストールします。
sudo ./svc.sh uninstall
-
パイプラインプールからエージェントを削除します。
./config.sh remove
-
設定ファイルを削除します。
cd ~ rm -rf ~/azagent
上記の手順を完了したら、エージェントのインストールと同じ手順を繰り返すことができます。
フライトマニュアル - 一斉配信メール
CLIツール で、ウィークリーニュースレターを送信します。 プロセスは次のとおりです。
-
DigitalOcean にサインインし、
Sendgrid
プロジェクトの下に新しい droplet を作成してください。 最新の日付の Ubuntu Sendgrid スナップショットを使用します。 これには データベースからメールをフェッチするスクリプトと CLI ツールがあらかじめロードされています。 現在の容量では、3 つの droplet でメールをタイムリーに送信できます。 -
メールリストをフェッチするスクリプトを設定します。
cd /home/freecodecamp/scripts/emails cp sample.env .env
.env
ファイルのプレイスホルダー値を認証情報に置き換える必要があります。 -
スクリプトを実行します。
node get-emails.js emails.csv
emails.csv
ファイルにメールリストを保存します。 -
必要な droplet の数に応じて、メールを複数のファイルに分割します。
scp
を使用してローカルにメールリストをプルし、お好みのテキストエディターを使用して複数のファイルに分割するのが最も簡単な方法です。 各ファイルに、email,unsubscribeId
ヘッダーが必要です。 -
cd /home/sendgrid-email-blast
で CLI ディレクトリに切り替え、ドキュメントに従って ツールを構成します。 -
使用ドキュメント に従って、ツールを実行してメールを送信します。
-
メールの一斉配信が完了したら、droplet を破棄する前に、メール送信に問題がなかったかどうかを確認します。
フライトマニュアル - 新規言語の新しいインスタンスの追加
テーマの変更
ニュースの掲載には、カスタム テーマ を使用します。 テーマに以下の変更を加えることで、新しい言語の追加が可能になります。
- 新規 ISO 言語コード の
else if
ステートメントをsetup-locale.js
に含めます。 assets/config/en
フォルダをコピーし、フォルダ名を新規言語コードに変更して、初期設定フォルダを作成します。 (スペイン語の場合は、en
—>es
となります)。- 新規言語フォルダ内で、
main.js
とfooter.js
の変数名を、該当言語のショートコードに変更します (スペイン語の場合は、enMain
—>esMain
となります)。 locales/en.json
をコピーして、新規言語コード名に変更します。partials/i18n.hbs
で、新たに作成された設定ファイルのスクリプトを追加します。- 関連する言語
day.js
スクリプトを cdnjs から freeCodeCamp CDN に追加します。
Ghost ダッシュボードの変更
Ghost ダッシュボード > 設定 > 一般と進み、出版物の アイコン、ロゴ および カバー をアップロードすることで、出版物アセットを更新します。