著者は、 Electronic Frontier Foundation を選択して、 Write forDOnationsプログラムの一環として寄付を受け取りました。
序章
Shipit は、Node.js開発者向けのユニバーサル自動化およびデプロイツールです。 人気のあるOrchestratorパッケージに基づくタスクフロー、 OpenSSH を介したログインとインタラクティブSSHコマンド、および拡張可能なAPIを備えています。 開発者はShipitを使用して、さまざまなNode.jsアプリケーションのビルドおよびデプロイメントワークフローを自動化できます。
Shipitワークフローを使用すると、開発者はタスクを構成するだけでなく、タスクを実行する順序を指定することもできます。 それらを同期的に実行するか非同期的に実行するか、およびどの環境で実行するか。
このチュートリアルでは、ローカル開発環境から本番環境にNode.jsアプリケーションをデプロイするようにShipitをインストールして構成します。 Shipitを使用して、アプリケーションをデプロイし、次の方法でリモートサーバーを構成します。
- Node.jsアプリケーションのファイルをローカル環境から本番環境に転送します（
rsync,git、 とssh). - アプリケーションの依存関係（ノードモジュール）をインストールします。
- PM2を使用してリモートサーバーで実行されているNode.jsプロセスを構成および管理します。
前提条件
このチュートリアルを開始する前に、次のものが必要です。
- 2台のCentOS7サーバー（このチュートリアルでは、appおよびwebという名前になります）は、Node.jsアプリケーションを本番環境にセットアップする方法に従ってプライベートネットワークで構成されます。 CentOS7チュートリアル。
- CentOS 7チュートリアルでLet’sEncryptを使用してNginxを保護する方法に示されているように、TLS / SSLで保護されたNginx（ web サーバー上）。 前提条件を時系列で実行している場合は、 web サーバーで手順1、4、および6を完了するだけでよいことに注意してください。
- Node.jsとnpmが開発環境にインストールされています。 このチュートリアルでは、バージョン10.17.0を使用します。 これをmacOSまたはUbuntu18.04にインストールするには、Node.jsをインストールしてmacOSにローカル開発環境を作成する方法またはのPPAを使用したインストール]セクションの手順に従います。 Ubuntu18.04にNode.jsをインストールする方法。 Node.jsをインストールすると、npmもインストールされます。 このチュートリアルではバージョン6.11.3を使用します。
- ローカル開発コンピュータと
rsyncとgitインストールされています。- macOSでは、Homebrewを使用してこれらをインストールできます。
- インストールするには
gitLinuxディストリビューションでは、Gitのインストール方法チュートリアルに従ってください。
- GitHubまたは別のホストされているアカウント
gitサービスプロバイダー。 このチュートリアルではGitHubを使用します。
注： Windowsユーザーは、このガイドのコマンドを実行するために、 Windows Subsystem forLinuxをインストールする必要があります。
ステップ1—リモートリポジトリの設定
Shipitでは、ローカル開発マシンとリモートサーバー間で同期するためにGitリポジトリが必要です。 このステップでは、にリモートリポジトリを作成します Github.com. 各プロバイダーはわずかに異なりますが、コマンドは多少転送可能です。
リポジトリを作成するには、 Github.com Webブラウザでログインします。 ページの右上隅に+の記号があることに気付くでしょう。 + をクリックし、新しいリポジトリをクリックします。
リポジトリの短くて覚えやすい名前を入力します。たとえば、 hello-world. ここで選択した名前はすべて、ローカルマシンで作業するプロジェクトフォルダーとして複製されることに注意してください。
必要に応じて、リポジトリの説明を追加します。
リポジトリの可視性を、パブリックまたはプライベートのいずれかの好みに設定します。
リポジトリがで初期化されていることを確認してください .gitignore、 選択する Node から Add .gitignore ドロップダウンリスト。 この手順は、不要なファイル（ node_modules フォルダ）リポジトリに追加されます。
リポジトリの作成ボタンをクリックします。
リポジトリは、からクローンを作成する必要があります Github.com ローカルマシンに。
ターミナルを開き、すべてのNode.jsプロジェクトファイルを保存する場所に移動します。 このプロセスにより、現在のディレクトリ内にサブフォルダが作成されることに注意してください。 リポジトリをローカルマシンに複製するには、次のコマンドを実行します。
- git clone https://github.com/your-github-username/your-github-repository-name.git
交換する必要があります your-github-username と your-github-repository-name Githubユーザー名と以前に提供されたリポジトリ名を反映します。
注：で2要素認証（2FA）を有効にしている場合 Github.com、コマンドラインでGithubにアクセスするときは、パスワードの代わりに個人用アクセストークンまたはSSHキーを使用する必要があります。 2FAに関連するGithubヘルプページには、の詳細情報が記載されています。
次のような出力が表示されます。
OutputCloning into 'your-github-repository-name'...
remote: Enumerating objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 3
Unpacking objects: 100% (3/3), done.
次のコマンドを実行して、リポジトリに移動します。
- cd your-github-repository-name
リポジトリ内には単一のファイルとフォルダーがあり、どちらもGitがリポジトリを管理するために使用するファイルです。 これは次の方法で確認できます。
- ls -la
次のような出力が表示されます。
Outputtotal 8
0 drwxr-xr-x 4 asciant staff 128 22 Apr 07:16 .
0 drwxr-xr-x 5 asciant staff 160 22 Apr 07:16 ..
0 drwxr-xr-x 13 asciant staff 416 22 Apr 07:16 .git
8 -rw-r--r-- 1 asciant staff 914 22 Apr 07:16 .gitignore
これで、動作を構成しました git リポジトリ、作成します shipit.js 展開プロセスを管理するファイル。
ステップ2—ShipitをNode.jsプロジェクトに統合する
このステップでは、サンプルのNode.jsプロジェクトを作成してから、Shipitパッケージを追加します。 このチュートリアルでは、サンプルアプリ、つまりHTTPリクエストを受け入れて応答するNode.js webサーバーを提供します。 Hello World プレーンテキストで。 アプリケーションを作成するには、次のコマンドを実行します。
- nano hello.js
次のサンプルアプリケーションコードをに追加します hello.js （更新 APP_PRIVATE_IP_ADDRESS app サーバーのプライベートネットワークIPアドレスへの変数）：
var http = require('http');
http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'text/plain'});
res.end('Hello World\n');
}).listen(8080, 'APP_PRIVATE_IP_ADDRESS');
console.log('Server running at http://APP_PRIVATE_IP_ADDRESS:8080/');
今あなたの package.json アプリケーションのファイル：
- npm init -y
このコマンドは、 package.json Node.jsアプリケーションを構成するために使用するファイル。 次のステップでは、このファイルに依存関係を追加します。 npm コマンドラインインターフェイス。
OutputWrote to ~/hello-world/package.json:
{
"name": "hello-world",
"version": "1.0.0",
"description": "",
"main": index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"keywords": [],
"author": "",
"license": "ISC"
}
次に、必要なものをインストールします npm 次のコマンドを使用したパッケージ：
- npm install --save-dev shipit-cli shipit-deploy shipit-shared
あなたは --save-dev Shipitパッケージはローカルマシンでのみ必要なので、ここでフラグを立ててください。 次のような出力が表示されます。
Output+ shipit-shared@4.4.2
+ shipit-cli@4.2.0
+ shipit-deploy@4.1.4
updated 4 packages and audited 21356 packages in 11.671s
found 62 low severity vulnerabilities run `npm audit fix` to fix them, or `npm audit` for details
これにより、3つのパッケージも追加されました package.json 開発依存関係としてのファイル：
. . .
"devDependencies": {
"shipit-cli": "^4.2.0",
"shipit-deploy": "^4.1.4",
"shipit-shared": "^4.4.2"
},
. . .
ローカル環境を構成したら、Shipitベースの展開用にリモートappサーバーの準備に進むことができます。
ステップ3—リモートアプリサーバーの準備
このステップでは、 ssh app サーバーに接続し、リモート依存関係をインストールします rsync. Rsyncは、ファイルの変更時間とサイズを比較することにより、ローカルコンピュータードライブ間およびネットワークコンピューター間でファイルを効率的に転送および同期するためのユーティリティです。
Shipitは rsync ローカルコンピュータとリモートappサーバー間でファイルを転送および同期します。 次のコマンドを発行することはありません rsync 直接; Shipitがあなたに代わってそれを処理します。
注： CentOS 7 で本番用にNode.jsアプリケーションをセットアップする方法では、2つのサーバーappとwebが残りました。 これらのコマンドは、appでのみ実行する必要があります。
経由でリモートappサーバーに接続します ssh:
- ssh deployer@your_app_server_ip
インストール rsync 次のコマンドを実行して、サーバー上で実行します。
- sudo yum install rsync
次のコマンドでインストールを確認します。
- rsync --version
このコマンドの出力内に同様の行が表示されます。
Outputrsync version 3.1.2 protocol version 31
. . .
あなたはあなたを終わらせることができます ssh 入力してセッション exit.
と rsync コマンドラインにインストールして利用できるようになったら、展開タスクとそれらのイベントとの関係に進むことができます。
ステップ4—デプロイメントタスクの構成と実行
イベントとタスクはどちらもShipitデプロイメントの主要コンポーネントであり、それらがアプリケーションのデプロイメントをどのように補完するかを理解することが重要です。 Shipitによってトリガーされるイベントは、展開ライフサイクルの特定のポイントを表します。 Shipitライフサイクルのシーケンスに基づいて、これらのイベントに応答してタスクが実行されます。
このタスク/イベントシステムがNode.jsアプリケーションで役立つ一般的な例は、アプリの依存関係のインストールです（node_modules）リモートサーバー上。 このステップの後半で、Shipitにリッスンさせます。 updated イベント（アプリケーションのファイルが転送された後に発行されます）およびタスクを実行して、アプリケーションの依存関係をインストールします（npm install）リモートサーバー上。
イベントをリッスンしてタスクを実行するには、リモートサーバー（ app サーバー）に関する情報を保持し、イベントリスナーとこれらのタスクによって実行されるコマンドを登録する構成ファイルが必要です。 このファイルは、Node.jsアプリケーションのディレクトリ内のローカル開発コンピューターにあります。
開始するには、リモートサーバー、サブスクライブするイベントリスナー、およびタスクの定義に関する情報を含むこのファイルを作成します。 作成 shipitfile.js 次のコマンドを実行して、ローカルマシンのアプリケーションルートディレクトリ内で次の操作を実行します。
- nano shipitfile.js
ファイルを作成したので、Shipitが必要とする初期環境情報をファイルに入力する必要があります。 これは主にリモートの場所です Git リポジトリ、そして重要なのは、appサーバーのパブリックIPアドレスとSSHユーザーアカウントです。
この初期構成を追加し、強調表示された行を環境に合わせて更新します。
module.exports = shipit => {
require('shipit-deploy')(shipit);
require('shipit-shared')(shipit);
const appName = 'hello';
shipit.initConfig({
default: {
deployTo: '/home/sammy/your-domain',
repositoryUrl: 'https://git-provider.tld/YOUR_GIT_USERNAME/YOUR_GIT_REPO_NAME.git',
keepReleases: 5,
shared: {
overwrite: true,
dirs: ['node_modules']
}
},
production: {
servers: 'sammy@YOUR_APP_SERVER_PUBLIC_IP'
}
});
const path = require('path');
const ecosystemFilePath = path.join(
shipit.config.deployTo,
'shared',
'ecosystem.config.js'
);
// Our listeners and tasks will go here
};
の変数を更新する shipit.initConfig メソッドは、Shipitにデプロイメントに固有の構成を提供します。 これらは、Shipitにとって次のことを表しています。
deployTo:Shipitがアプリケーションのコードをリモートサーバーにデプロイするディレクトリです。 ここでは、/home/非rootユーザー用のフォルダsudo特権（/home/sammy）安全であり、許可の問題を回避します。 The/your-domainコンポーネントは、ユーザーのホームフォルダー内の他のフォルダーとフォルダーを区別するための命名規則です。repositoryUrl:は完全なGitリポジトリへのURLです。ShipitはこのURLを使用して、デプロイ前にプロジェクトファイルが同期されていることを確認します。keepReleases:リモートサーバーに保持するリリースの数です。 Areleaseは、リリース時のアプリケーションのファイルを含む日付がスタンプされたフォルダです。 これらは次の場合に役立ちますrollback展開の。shared:に対応する構成ですkeepReleasesこれにより、ディレクトリをsharedリリース間。 この例では、単一のnode_modulesすべてのリリース間で共有されるフォルダー。production:アプリケーションをデプロイするリモートサーバーを表します。 この例では、名前を付けた単一のサーバー（ app サーバー）がありますproduction、 とともにservers:SSHに一致する構成userとpublic ip address. 名前production、このチュートリアルの最後に使用されるShipitデプロイコマンドに対応します（npx shipit server name deployまたはあなたの場合npx shipit production deploy).
Shipit Deploy Configuration オブジェクトの詳細については、ShipitGithubリポジトリを参照してください。
更新を続行する前に shipitfile.js、Shipitタスクを理解するために、次のサンプルコードスニペットを確認しましょう。
Example event listenershipit.on('deploy', () => {
shipit.start('say-hello');
});
shipit.blTask('say-hello', async () => {
shipit.local('echo "hello from your local computer"')
});
これは、を使用するタスクの例です。 shipit.on サブスクライブする方法 deploy イベント。 このタスクは deploy Shipitライフサイクルによって発行されるイベント。イベントが受信されると、タスクは shipit.start Shipitに指示するメソッド start the say-hello 仕事。
The shipit.on メソッドは、リッスンするイベントの名前と、イベントの受信時に実行するコールバック関数の2つのパラメーターを取ります。
下 shipit.on メソッド宣言、タスクはで定義されます shipit.blTask 方法。 これにより、実行中に他のタスクをブロックする新しいShipitタスクが作成されます（これは同期タスクです）。 The shipit.blTask メソッドは、定義しているタスクの名前と、タスクがによってトリガーされたときに実行するコールバック関数の2つのパラメーターも受け取ります。 shipit.start.
このサンプルタスクのコールバック関数内（say-hello）、 shipit.local メソッドは、ローカルマシンでコマンドを実行します。 ローカルコマンドはエコーします "hello from your local computer" 端子出力に。
リモートサーバーでコマンドを実行する場合は、 shipit.remote 方法。 2つの方法、 shipit.local と shipit.remote、デプロイメントの一部としてローカルまたはリモートでコマンドを発行するためのAPIを提供します。
今すぐ更新します shipitfile.js Shipitライフサイクルにサブスクライブするイベントリスナーを含める shipit.on. イベントリスナーをあなたに追加します shipitfile.js、初期構成のコメントプレースホルダーの後に挿入します // Our tasks will go here:
. . .
shipit.on('updated', () => {
shipit.start('npm-install', 'copy-config');
});
shipit.on('published', () => {
shipit.start('pm2-server');
});
これらの2つの方法は、 updated そしてその published Shipitデプロイメントライフサイクルの一部として発行されるイベント。 イベントを受信すると、それぞれがを使用してタスクを開始します shipit.start 例のタスクと同様のメソッド。
リスナーをスケジュールしたので、対応するタスクを追加します。 次のタスクを shipitfile.js、イベントリスナーの後に挿入します。
. . .
shipit.blTask('copy-config', async () => {
const fs = require('fs');
const ecosystem = `
module.exports = {
apps: [
{
name: '${appName}',
script: '${shipit.releasePath}/hello.js',
watch: true,
autorestart: true,
restart_delay: 1000,
env: {
NODE_ENV: 'development'
},
env_production: {
NODE_ENV: 'production'
}
}
]
};`;
fs.writeFileSync('ecosystem.config.js', ecosystem, function(err) {
if (err) throw err;
console.log('File created successfully.');
});
await shipit.copyToRemote('ecosystem.config.js', ecosystemFilePath);
});
最初にというタスクを宣言します copy-config. このタスクは、というローカルファイルを作成します ecosystem.config.js 次に、そのファイルをリモートのappサーバーにコピーします。 PM2 このファイルを使用してNode.jsアプリケーションを管理します。 に必要なファイルパス情報を提供します PM2 最新のデプロイ済みファイルが実行されていることを確認します。 ビルドプロセスの後半で、実行するタスクを作成します PM2 と ecosystem.config.js 構成として。
アプリケーションで環境変数（データベース接続文字列など）が必要な場合は、ローカルで宣言できます。 env: またはのリモートサーバー上 env_production: 設定したのと同じ方法で NODE_ENV これらのオブジェクトの変数。
次のタスクを shipitfile.js 次の copy-config 仕事：
. . .
shipit.blTask('npm-install', async () => {
shipit.remote(`cd ${shipit.releasePath} && npm install --production`);
});
次に、というタスクを宣言します npm-install. このタスクは、リモートbashターミナルを使用します（ shipit.remote）アプリの依存関係をインストールする（npm パッケージ）。
最後のタスクを shipitfile.js 次の npm-install 仕事：
. . .
shipit.blTask('pm2-server', async () => {
await shipit.remote(`pm2 delete -s ${appName} || :`);
await shipit.remote(
`pm2 start ${ecosystemFilePath} --env production --watch true`
);
});
最後に、というタスクを宣言します pm2-server. このタスクでは、リモートbash端末を使用して最初に停止します PM2 以前の展開の管理から delete コマンドを実行してから、Node.jsサーバーの新しいインスタンスを起動して ecosystem.config.js 変数としてのファイル。 あなたも PM2 からの環境変数を使用する必要があることを知っている production 初期構成でブロックすると、 PM2 アプリケーションを監視し、クラッシュした場合は再起動します。
完全な shipitfile.js ファイル：
module.exports = shipit => {
require('shipit-deploy')(shipit);
require('shipit-shared')(shipit);
const appName = 'hello';
shipit.initConfig({
default: {
deployTo: '/home/deployer/example.com',
repositoryUrl: 'https://git-provider.tld/YOUR_GIT_USERNAME/YOUR_GIT_REPO_NAME.git',
keepReleases: 5,
shared: {
overwrite: true,
dirs: ['node_modules']
}
},
production: {
servers: 'deployer@YOUR_APP_SERVER_PUBLIC_IP'
}
});
const path = require('path');
const ecosystemFilePath = path.join(
shipit.config.deployTo,
'shared',
'ecosystem.config.js'
);
// Our listeners and tasks will go here
shipit.on('updated', async () => {
shipit.start('npm-install', 'copy-config');
});
shipit.on('published', async () => {
shipit.start('pm2-server');
});
shipit.blTask('copy-config', async () => {
const fs = require('fs');
const ecosystem = `
module.exports = {
apps: [
{
name: '${appName}',
script: '${shipit.releasePath}/hello.js',
watch: true,
autorestart: true,
restart_delay: 1000,
env: {
NODE_ENV: 'development'
},
env_production: {
NODE_ENV: 'production'
}
}
]
};`;
fs.writeFileSync('ecosystem.config.js', ecosystem, function(err) {
if (err) throw err;
console.log('File created successfully.');
});
await shipit.copyToRemote('ecosystem.config.js', ecosystemFilePath);
});
shipit.blTask('npm-install', async () => {
shipit.remote(`cd ${shipit.releasePath} && npm install --production`);
});
shipit.blTask('pm2-server', async () => {
await shipit.remote(`pm2 delete -s ${appName} || :`);
await shipit.remote(
`pm2 start ${ecosystemFilePath} --env production --watch true`
);
});
};
準備ができたら、ファイルを保存して終了します。
あなたと shipitfile.js 構成済み、イベントリスナー、および関連するタスクが完了したら、appサーバーへのデプロイに進むことができます。
ステップ5—アプリケーションのデプロイ
このステップでは、アプリケーションをリモートで展開し、展開によってアプリケーションがインターネットで利用できるようになったことをテストします。
ShipitはリモートGitリポジトリからプロジェクトファイルを複製するため、ローカルNode.jsアプリケーションファイルをローカルマシンからGithubにプッシュする必要があります。 Node.jsプロジェクトのアプリケーションディレクトリ（ hello.js と shiptitfile.js が見つかりました）、次のコマンドを実行します。
- git status
The git status コマンドは、作業ディレクトリとステージング領域の状態を表示します。 どの変更がステージングされているか、どの変更がステージングされていないか、どのファイルがGitによって追跡されていないかを確認できます。 ファイルは追跡されておらず、出力に赤で表示されます。
OutputOn branch master
Your branch is up to date with 'origin/master'.
Untracked files:
(use "git add <file>..." to include in what will be committed)
hello.js
package-lock.json
package.json
shipitfile.js
nothing added to commit but untracked files present (use "git add" to track)
次のコマンドを使用して、これらのファイルをリポジトリに追加できます。
- git add --all
このコマンドを実行した場合でも、このコマンドは出力を生成しません。 git status この場合も、コミットする変更があることに注意して、ファイルは緑色で表示されます。
次のコマンドを実行してコミットを作成できます。
- git commit -m "Our first commit"
このコマンドの出力は、ファイルに関するGit固有の情報を提供します。
Output[master c64ea03] Our first commit
4 files changed, 1948 insertions(+)
create mode 100644 hello.js
create mode 100644 package-lock.json
create mode 100644 package.json
create mode 100644 shipitfile.js
残っているのは、Shipitがデプロイ中にappサーバーにクローンを作成するためにコミットをリモートリポジトリにプッシュすることだけです。 次のコマンドを実行します。
- git push origin master
出力には、リモートリポジトリとの同期に関する情報が含まれます。
OutputEnumerating objects: 7, done.
Counting objects: 100% (7/7), done.
Delta compression using up to 8 threads
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 15.27 KiB | 7.64 MiB/s, done.
Total 6 (delta 0), reused 0 (delta 0)
To github.com:Asciant/hello-world.git
e274312..c64ea03 master -> master
アプリケーションをデプロイするには、次のコマンドを実行します。
- npx shipit production deploy
このコマンドの出力（全体を含めるには大きすぎる）は、実行されているタスクと特定の機能の結果の詳細を提供します。 次の出力 pm2-server タスクは、Node.jsアプリが起動されたことを示しています。
OutputRunning 'deploy:init' task...
Finished 'deploy:init' after 432 μs
. . .
Running 'pm2-server' task...
Running "pm2 delete -s hello || :" on host "centos-ap-app.asciant.com".
Running "pm2 start /home/deployer/example.com/shared/ecosystem.config.js --env production --watch true" on host "centos-ap-app.asciant.com".
@centos-ap-app.asciant.com [PM2][WARN] Node 4 is deprecated, please upgrade to use pm2 to have all features
@centos-ap-app.asciant.com [PM2][WARN] Applications hello not running, starting...
@centos-ap-app.asciant.com [PM2] App [hello] launched (1 instances)
@centos-ap-app.asciant.com ┌──────────┬────┬─────────┬──────┬──────┬────────┬─────────┬────────┬─────┬──────────┬──────────┬──────────┐
@centos-ap-app.asciant.com │ App name │ id │ version │ mode │ pid │ status │ restart │ uptime │ cpu │ mem │ user │ watching │
@centos-ap-app.asciant.com ├──────────┼────┼─────────┼──────┼──────┼────────┼─────────┼────────┼─────┼──────────┼──────────┼──────────┤
@centos-ap-app.asciant.com │ hello │ 0 │ 1.0.0 │ fork │ 4177 │ online │ 0 │ 0s │ 0% │ 4.5 MB │ deployer │ enabled │
@centos-ap-app.asciant.com └──────────┴────┴─────────┴──────┴──────┴────────┴─────────┴────────┴─────┴──────────┴──────────┴──────────┘
@centos-ap-app.asciant.com Use `pm2 show <id|name>` to get more details about an app
Finished 'pm2-server' after 5.27 s
Running 'deploy:clean' task...
Keeping "5" last releases, cleaning others
Running "(ls -rd /home/deployer/example.com/releases/*|head -n 5;ls -d /home/deployer/example.com/releases/*)|sort|uniq -u|xargs rm -rf" on host "centos-ap-app.asciant.com".
Finished 'deploy:clean' after 1.81 s
Running 'deploy:finish' task...
Finished 'deploy:finish' after 222 μs
Finished 'deploy' [ deploy:init, deploy:fetch, deploy:update, deploy:publish, deploy:clean, deploy:finish ]
アプリケーションをユーザーのように表示するには、WebサイトのURLを入力します your-domain ブラウザでwebサーバーにアクセスします。 これにより、ファイルがデプロイされた app サーバー上で、リバースプロキシを介してNode.jsアプリケーションが提供されます。
HelloWorldの挨拶が表示されます。
注：最初のデプロイ後、Gitリポジトリは新しく作成されたファイルを追跡します。 ecosystem.config.js. このファイルはデプロイごとに再構築され、コンパイルされたアプリケーションシークレットが含まれている可能性があるため、 .gitignore 次の前に、ローカルマシンのアプリケーションルートディレクトリにあるファイル git 専念。
. . .
# ecosystem.config
ecosystem.config.js
Node.jsアプリケーションをappサーバーにデプロイしました。これは、新しいデプロイメントを指します。 すべてが稼働している状態で、アプリケーションプロセスの監視に進むことができます。
ステップ6—アプリケーションの監視
PM2は、リモートプロセスを管理するための優れたツールですが、これらのアプリケーションプロセスのパフォーマンスを監視する機能も提供します。
次のコマンドを使用して、SSH経由でリモートappサーバーに接続します。
- ssh deployer@your_app_server_ip
PM2管理対象プロセスに関連する特定の情報を取得するには、以下を実行します。
- pm2 list
次のような出力が表示されます。
Output┌─────────────┬────┬─────────┬──────┬──────┬────────┬─────────┬────────┬──────┬───────────┬──────────┬──────────┐
│ App name │ id │ version │ mode │ pid │ status │ restart │ uptime │ cpu │ mem │ user │ watching │
├─────────────┼────┼─────────┼──────┼──────┼────────┼─────────┼────────┼──────┼───────────┼──────────┼──────────┤
│ hello │ 0 │ 0.0.1 │ fork │ 3212 │ online │ 0 │ 62m │ 0.3% │ 45.2 MB │ deployer │ enabled │
└─────────────┴────┴─────────┴──────┴──────┴────────┴─────────┴────────┴──────┴───────────┴──────────┴──────────┘
PM2が収集した情報の概要が表示されます。 詳細情報を表示するには、次のコマンドを実行できます。
- pm2 show hello
出力は、によって提供される要約情報を拡張します。 pm2 list 指図。 また、いくつかの補助コマンドに関する情報を提供し、ログファイルの場所を提供します。
Output Describing process with id 0 - name hello
┌───────────────────┬─────────────────────────────────────────────────────────────┐
│ status │ online │
│ name │ hello │
│ version │ 1.0.0 │
│ restarts │ 0 │
│ uptime │ 82s │
│ script path │ /home/deployer/example.com/releases/20190531213027/hello.js │
│ script args │ N/A │
│ error log path │ /home/deployer/.pm2/logs/hello-error.log │
│ out log path │ /home/deployer/.pm2/logs/hello-out.log │
│ pid path │ /home/deployer/.pm2/pids/hello-0.pid │
│ interpreter │ node │
│ interpreter args │ N/A │
│ script id │ 0 │
│ exec cwd │ /home/deployer │
│ exec mode │ fork_mode │
│ node.js version │ 4.2.3 │
│ node env │ production │
│ watch & reload │ ✔ │
│ unstable restarts │ 0 │
│ created at │ 2019-05-31T21:30:48.334Z │
└───────────────────┴─────────────────────────────────────────────────────────────┘
Revision control metadata
┌──────────────────┬────────────────────────────────────────────────────┐
│ revision control │ git │
│ remote url │ N/A │
│ repository root │ /home/deployer/example.com/releases/20190531213027 │
│ last update │ 2019-05-31T21:30:48.559Z │
│ revision │ 62fba7c8c61c7769022484d0bfa46e756fac8099 │
│ comment │ Our first commit │
│ branch │ master │
└──────────────────┴────────────────────────────────────────────────────┘
Divergent env variables from local env
┌───────────────────────────┬───────────────────────────────────────┐
│ XDG_SESSION_ID │ 15 │
│ HOSTNAME │ N/A │
│ SELINUX_ROLE_REQUESTED │ │
│ TERM │ N/A │
│ HISTSIZE │ N/A │
│ SSH_CLIENT │ 44.222.77.111 58545 22 │
│ SELINUX_USE_CURRENT_RANGE │ │
│ SSH_TTY │ N/A │
│ LS_COLORS │ N/A │
│ MAIL │ /var/mail/deployer │
│ PATH │ /usr/local/bin:/usr/bin │
│ SELINUX_LEVEL_REQUESTED │ │
│ HISTCONTROL │ N/A │
│ SSH_CONNECTION │ 44.222.77.111 58545 209.97.167.252 22 │
└───────────────────────────┴───────────────────────────────────────┘
. . .
PM2は、次の方法でアクセスできる端末内監視ツールも提供します。
- pm2 monit
このコマンドの出力は、インタラクティブなダッシュボードです。 pm2 リアルタイムのプロセス情報、ログ、メトリック、およびメタデータを提供します。 このダッシュボードは、リソースとエラーログの監視に役立つ場合があります。
Output┌─ Process list ────────────────┐┌─ Global Logs ─────────────────────────────────────────────────────────────┐
│[ 0] hello Mem: 22 MB ││ │
│ ││ │
│ ││ │
└───────────────────────────────┘└───────────────────────────────────────────────────────────────────────────┘
┌─ Custom metrics (http://bit.l─┐┌─ Metadata ────────────────────────────────────────────────────────────────┐
│ Heap Size 10.73 ││ App Name hello │
│ Heap Usage 66.14 ││ Version N/A │
│ Used Heap Size 7.10 ││ Restarts 0 │
│ Active requests 0 ││ Uptime 55s │
│ Active handles 4 ││ Script path /home/asciant/hello.js │
│ Event Loop Latency 0.70 ││ Script args N/A │
│ Event Loop Latency p95 ││ Interpreter node │
│ ││ Interpreter args N/A │
└───────────────────────────────┘└───────────────────────────────────────────────────────────────────────────┘
PM2を使用してプロセスを監視する方法を理解したら、Shipitが以前の作業展開へのロールバックを支援する方法に進むことができます。
あなたの終わり ssh appサーバーでセッションを実行して exit.
ステップ7—バグのある展開をロールバックする
展開により、予期しないバグや、サイトの障害を引き起こす問題が発生することがあります。 Shipitの開発者とメンテナーはこれを予期しており、アプリケーションの以前の（機能している）デプロイメントにロールバックする機能を提供しています。
あなたの PM2 構成が持続する場合は、別のイベントリスナーを追加します shipitfile.js に rollback イベント：
. . .
shipit.on('rollback', () => {
shipit.start('npm-install', 'copy-config');
});
リスナーを追加します rollback あなたを実行するイベント npm-install と copy-config タスク。 これが必要なのは、 published イベント、 updated デプロイメントをロールバックするときに、イベントはShipitライフサイクルによって実行されません。 このイベントリスナーを追加すると、 PM2 プロセスマネージャは、ロールバックが発生した場合でも、最新の展開を示します。
このプロセスはデプロイに似ていますが、コマンドが少し変更されています。 以前のデプロイメントにロールバックするために、以下を実行できます。
- npx shipit production rollback
以下のような deploy 指図、 rollback ロールバックプロセスと実行中のタスクの詳細を提供します。
OutputRunning 'rollback:init' task...
Get current release dirname.
Running "if [ -h /home/deployer/example.com/current ]; then readlink /home/deployer/example.com/current; fi" on host "centos-ap-app.asciant.com".
@centos-ap-app.asciant.com releases/20190531213719
Current release dirname : 20190531213719.
Getting dist releases.
Running "ls -r1 /home/deployer/example.com/releases" on host "centos-ap-app.asciant.com".
@centos-ap-app.asciant.com 20190531213719
@centos-ap-app.asciant.com 20190531213519
@centos-ap-app.asciant.com 20190531213027
Dist releases : ["20190531213719","20190531213519","20190531213027"].
Will rollback to 20190531213519.
Finished 'rollback:init' after 3.96 s
Running 'deploy:publish' task...
Publishing release "/home/deployer/example.com/releases/20190531213519"
Running "cd /home/deployer/example.com && if [ -d current ] && [ ! -L current ]; then echo "ERR: could not make symlink"; else ln -nfs releases/20190531213519 current_tmp && mv -fT current_tmp current; fi" on host "centos-ap-app.asciant.com".
Release published.
Finished 'deploy:publish' after 1.8 s
Running 'pm2-server' task...
Running "pm2 delete -s hello || :" on host "centos-ap-app.asciant.com".
Running "pm2 start /home/deployer/example.com/shared/ecosystem.config.js --env production --watch true" on host "centos-ap-app.asciant.com".
@centos-ap-app.asciant.com [PM2][WARN] Node 4 is deprecated, please upgrade to use pm2 to have all features
@centos-ap-app.asciant.com [PM2][WARN] Applications hello not running, starting...
@centos-ap-app.asciant.com [PM2] App [hello] launched (1 instances)
@centos-ap-app.asciant.com ┌──────────┬────┬─────────┬──────┬──────┬────────┬─────────┬────────┬─────┬──────────┬──────────┬──────────┐
@centos-ap-app.asciant.com │ App name │ id │ version │ mode │ pid │ status │ restart │ uptime │ cpu │ mem │ user │ watching │
@centos-ap-app.asciant.com ├──────────┼────┼─────────┼──────┼──────┼────────┼─────────┼────────┼─────┼──────────┼──────────┼──────────┤
@centos-ap-app.asciant.com │ hello │ 0 │ 1.0.0 │ fork │ 4289 │ online │ 0 │ 0s │ 0% │ 4.5 MB │ deployer │ enabled │
@centos-ap-app.asciant.com └──────────┴────┴─────────┴──────┴──────┴────────┴─────────┴────────┴─────┴──────────┴──────────┴──────────┘
@centos-ap-app.asciant.com Use `pm2 show <id|name>` to get more details about an app
Finished 'pm2-server' after 5.55 s
Running 'deploy:clean' task...
Keeping "5" last releases, cleaning others
Running "(ls -rd /home/deployer/example.com/releases/*|head -n 5;ls -d /home/deployer/example.com/releases/*)|sort|uniq -u|xargs rm -rf" on host "centos-ap-app.asciant.com".
Finished 'deploy:clean' after 1.82 s
Running 'rollback:finish' task...
Finished 'rollback:finish' after 615 μs
Finished 'rollback' [ rollback:init, deploy:publish, deploy:clean, rollback:finish ]
Shipitを構成して、5つのリリースを保持します。 keepReleases: 5 の構成 shipitfile.js. Shipitはこれらのリリースを内部で追跡し、必要なときにロールバックできるようにします。 Shipitは、タイムスタンプという名前のディレクトリを作成することにより、リリースを識別する便利な方法も提供します（YYYYMMDDHHmmss-例： /home/deployer/your-domain/releases/20190420210548).
ロールバックプロセスをさらにカスタマイズしたい場合は、ロールバック操作に固有のイベントをリッスンできます。 次に、これらのイベントを使用して、ロールバックを補完するタスクを実行できます。 Shipitライフサイクルの内訳で提供されるイベントリストを参照して、タスク/リスナーを構成できます。 shipitfile.js.
ロールバックできるということは、デプロイメントによって予期しないバグや問題が発生した場合でも、機能しているバージョンのアプリケーションを常にユーザーに提供できることを意味します。
結論
このチュートリアルでは、いくつかのサーバーから、Platform asaServiceの高度にカスタマイズ可能な代替手段を作成できるワークフローを構成しました。 このワークフローにより、カスタマイズされた展開と構成、PM2を使用したプロセスの監視、サービスの拡張と追加の可能性、または必要に応じて展開にサーバーや環境を追加できます。
Node.jsスキルの開発を継続することに興味がある場合は、DigtalOceanNode.jsコンテンツとNode.jsシリーズのコーディング方法を確認してください。
