Webアプリケーションを作成および公開するためのチェックリスト

最近、独自のウェブアプリケーションを作成するためには、それを開発するだけでは不十分です。 重要な側面は、アプリケーションの展開、監視、およびそれが動作する環境の管理のためのツールのセットアップです。 手動展開の時代は忘れられつつあります。小さなプロジェクトであっても、自動化ツールは具体的なメリットをもたらします。 「手動」で展開すると、何かを転送することを忘れたり、1つまたは別のニュアンスを考慮に入れたり、忘れられたテストを実行したりすることがよくあります。



この記事は、Webアプリケーションの作成の基本だけを理解し、基本的な用語と規則について少し理解したい人に役立ちます。



そのため、アプリケーションの構築は依然として2つの部分に分割できます。これは、アプリケーションコードに関連するものと、このコードが実行される環境に関連するものです。 アプリケーションコードは、サーバー（サーバー上で実行されるもの、多くの場合：ビジネスロジック、承認、データストレージなど）とクライアント（ユーザーのマシン上で実行されるもの：多くの場合、インターフェイス、および関連するそれにロジック）。



水曜日から始めましょう。



コード、システム、ソフトウェアの動作の基礎はオペレーティングシステムです。以下では、ホスティング市場で最も人気のあるシステムを見て、簡単に説明します。



Windows Serverは同じWindowsですが、サーバーのバリエーションが異なります。 クライアントの（通常の）バージョンのWindowsで使用できる機能、たとえば統計収集サービス、および同様のソフトウェアはここにはありませんが、ネットワーク管理用のユーティリティセット、サーバー展開用の基本ソフトウェア（web、ftpなど）があります。 一般に、Windows Serverは通常のWindowsのように見えますが、通常のWindowsのように見えますが、通常のWindowsの2倍の費用がかかります。 ただし、専用/仮想サーバーにアプリケーションを展開する可能性が最も高いことを考えると、最終的なコストは増加する可能性がありますが、重要ではありません。 WindowsプラットフォームはユーザーOSの市場で圧倒的な地位を占めているため、そのサーバーエディションはほとんどのユーザーにとって最も馴染みのあるものになります。



Unixライクなシステム。 これらのシステムでの従来の作業は、使い慣れたグラフィカルインターフェイスを意味するものではなく、コントロール要素としてコンソールのみをユーザーに提供します。 経験の浅いユーザーにとって、そのような形式での作業は難しく、データで非常に人気のあるVimテキストエディターだけが残されます。これに関連する6年間の質問は、すでに180万ビューを超えています。 このファミリーの主なディストリビューション（エディション）は次のとおりです。Debian-人気のあるディストリビューション、そのパッケージバージョンは主にLTS（ 長期サポート -長期間のサポート）に焦点を当てています。これはシステムとパッケージのかなり高い信頼性と安定性に反映されています; Ubuntu-すべてのパッケージのディストリビューションが最新バージョンに含まれているため、安定性に影響する可能性がありますが、新しいバージョンに付属の機能を使用できます。 Red Hat Enterprise Linux-商用目的で販売されているOSは有料ですが、ソフトウェアプロバイダー、一部のプロプライエタリおよびドライバーパッケージからのサポートが含まれています。 CentOS- Red Hat Enterprise Linuxのオープンソース版で、独自のパッケージとサポートがないことを特徴としています。



この分野の開発のみを理解している人には、 Windows ServerまたはUbuntuをお勧めします 。 Windowsを検討する場合、これは主にシステムの習慣であり、 Ubuntu-更新に対する耐性が高いため、たとえば、新しいバージョンを必要とするテクノロジーでプロジェクトを開始するときの問題が少なくなります。



したがって、OSを決定したら、アプリケーションまたはサーバー上のその部分の状態を展開（インストール）、更新、および監視できるツールのセットに移りましょう。



次の重要な決定は、アプリケーションとサーバーをホストすることです。 現時点では、最も一般的な3つの方法があります。

• 自分でサーバーをホスト（維持）するのが最も予算のオプションですが、リソースがアドレスを経時的に変更しないように、プロバイダーに静的IPを注文する必要があります。
  
  
• 専用サーバー（VDS）をレンタルし、その管理と負荷のスケーリングを個別に管理します
  
  
• 一部のクラウドホスティングでサブスクリプションを支払う（多くの場合、同時にプラットフォーム機能を無料で提供します）場合、使用済みリソースの支払いモデルは非常に一般的です。 この方向の最も著名な代表者：Amazon AWS（サービスの無料使用年を与えますが、月額制限付き）、Google Cloud（クラウドホスティングサービスに年間使用できるアカウントに300ドルを与えます）、Yandex。Cloud（4000ルーブルを与えます） 。（2か月間）、Microsoft Azure（人気のあるサービスへの1年間の無料アクセス、1か月のサービスに対して12 500ルーブル）。 したがって、これらのプロバイダーのいずれかをわずかな費用をかけずに試すことができますが、サービスの品質とレベルに関するおおよその意見を取得できます。
  
  

選択されたパスに応じて、事実のみが将来変更されますが、ほとんどの場合、特定の管理領域に対する責任は誰にあります。 自分でホストしている場合は、電気、インターネット、サーバー自体、そこに展開されているソフトウェアのすべての中断を理解する必要があります。これらはすべてあなたの肩にかかっています。 ただし、トレーニングとテストについては、これで十分です。



サーバーの役割を果たすことができる追加のマシンがない場合は、2番目または3番目の方法を使用します。 2番目のケースは最初のケースと同じです。ただし、サーバーの可用性に対する責任とホストの肩への権限をシフトします。 サーバーおよびソフトウェアの管理は引き続き管理できます。



そして最後に、クラウドプロバイダーの力を借りるオプション。 ここでは、技術的なニュアンスをあまり必要とせずに、ほとんどすべての自動制御を構成できます。 さらに、1台のマシンの代わりに、複数のインスタンス（インスタンス）を並行して実行することができます。たとえば、専用サーバーの所有権とあまりコストをかけずに、アプリケーションのさまざまな部分を担当できます。 また、オーケストレーション、コンテナ化、自動展開、継続的インテグレーションなどの手段もあります！ これらのことのいくつかを以下で検討します。



一般的に、サーバーインフラストラクチャは次のとおりです。サーバーインスタンスの環境の変更を管理するいわゆる「オーケストレーター」（「オーケストレーション」-複数のサーバーインスタンスを管理するプロセス）、アプリケーションを分割できる仮想化コンテナー（オプションですが、よく使用されます）があります分離された論理層、および継続的統合用のソフトウェア-ホストされたコードを「スクリプト」で更新できます。



したがって、オーケストレーションでは、サーバーの状態を確認したり、サーバー環境の更新をロールバックまたはロールバックしたりできます。 最初に、この側面はあなたに関係しそうにありません。何かとオーケストレーションするためには、複数のサーバーが必要です（1つは必要ですが、なぜ必要なのですか？）、そして複数のサーバーがあるためにはそれらが必要です。 この分野のツールのうち、ほとんどがGoogleが開発したKubernetesです。



次のステップは、OSレベルでの仮想化です。 現在、「ドッカー化」の概念は広く普及しています。これは、互いに分離されたコンテナの機能を提供するが、同じオペレーティングシステムのコンテキストで起動されるDockerツールに由来します。 これが意味すること：これらのコンテナのそれぞれで、このマシン上の他の誰かの存在を知らなくても、アプリケーション、またはそれらがOS全体で唯一のものであると仮定するアプリケーションのセットを実行できます。 この機能は、異なるバージョンの同じアプリケーションを起動する場合や、単に競合するアプリケーションを起動する場合、およびアプリケーションの一部をレイヤーに分割する場合の両方に非常に役立ちます。 このレイヤーのキャストは、その後、たとえばアプリケーションをデプロイするために使用できるイメージに書き込むことができます。 つまり、このイメージをインストールし、それに含まれるコンテナーを展開すると、アプリケーションを起動するための既製の環境が得られます！ 最初のステップでは、このツールを教育目的とアプリケーションロジックを異なるレイヤーに広げることで非常に大きな利益を得るために使用できます。 しかし、誰もがドッキングを必要とするわけではなく、常に必要ではないことをここで言う価値があります。 ドッキングは、アプリケーションが「断片化」され、小さな部分に分割され、それぞれが独自のタスク、いわゆる「マイクロサービスアーキテクチャ」を担当する場合に正当化されます。



環境の提供に加えて、あらゆる種類のコード変換、アプリケーションに関連するライブラリとパッケージのインストール、テストの実行、これらの操作に関する通知などを含む、アプリケーションの適切な展開を提供する必要があります。 ここでは、「継続的インテグレーション」（ CI-継続的インテグレーション ）などの概念に注意する必要があります。 現在、この分野の主なツールはJenkins（Javaで書かれたCIのソフトウェアは最初は少し複雑に見えるかもしれません）、 Travis CI （Rubyで書かれ、主観的にはJenkinsよりもややシンプルですが、展開構成エリア）、 Gitlab CI （ Ruby and Goで記述）。



そのため、アプリケーションが動作する環境について説明した後、最終的に、現代の世界がこれらのアプリケーションを作成するためにどのようなツールを提供しているかを確認します。



基本から始めましょう： バックエンド （バックエンド）-サーバー側。 ここでの言語の選択、基本機能のセット、および事前定義された構造（フレームワーク）は、主に個人の好みによって決定されますが、それでも検討のために言及する価値があります（言語についての著者の意見は、公平な説明に対する主張にもかかわらず、非常に主観的です）：

• Pythonは経験の浅いユーザーにとっても十分に使いやすい言語であり、いくつかの間違いを許しますが、開発者にとっては非常に厳しく、悪いことは何もしません。 1991年に登場した、すでにかなり成熟した意味のあるPL。
  
  
• GoはGoogleの言語であり、非常に友好的で便利です。どのプラットフォームでも実行ファイルをコンパイルして取得するのは簡単です。 シンプルで楽しいこともあれば、難しくて深刻なこともあります。 新鮮で若く、2009年に比較的最近登場しました。
• Rust-2006年にリリースされた前の同僚より少し年上ですが、彼の兄弟に関してはまだかなり若いです。 プログラマ向けの多くの低レベルのタスクを解決しようとしていますが、より経験豊富な開発者を対象としています。
• Javaは1995年に登場した商用開発のベテランであり、現在エンタープライズアプリケーション開発で最も一般的に使用されている言語の1つです。 基本的な概念とランタイム環境の高度なチューニングにより、初心者にとってはかなり複雑になる可能性があります。
• ASP.netは、Microsoftがリリースしたアプリケーション開発プラットフォームです。 関数を書くために、2000年に登場した言語C＃（C Sharpと発音）が主に使用されます。 その複雑さは、JavaとRustのレベルに匹敵します。
• PHP-当初はHTMLの前処理に使用されていましたが、現在のところ、言語市場では絶対的なリーダーシップを維持していますが、使用が減少する傾向があります。 エントリのしきい値が低く、コードの記述が簡単ですが、同時に、十分な大きさのアプリケーションを開発する場合、言語の機能が十分でない可能性があります。

さて、アプリケーションの最後の部分-ユーザーにとって最も具体的なもの- フロントエンド （フロントエンド）-はアプリケーションの表面であり、ユーザーが直接対話するのはこの部分です。



詳細には触れませんが、最新のフロントエンドは、ユーザーインターフェイスを作成するための3つの柱であるフレームワーク（それほどではありません）に基づいています。 したがって、最も人気のある3つは次のとおりです。

• ReactJSはフレームワークではなく、ライブラリです。 実際、このフレームワークは、一部の機能が「すぐに使用可能」であり、それらを手動でインストールする必要がある場合のみ、誇りのあるタイトルと異なります。 したがって、このライブラリの「準備」にはいくつかのバリエーションがあり、一種のフレームワークを形成します。 初心者にとっては、いくつかの基本原則と、アセンブリ環境の非常に積極的なセットアップのために、複雑になる可能性があります。 ただし、クイックスタートのために、「create-react-app」パッケージを使用できます。
• VueJSは、カスタムインターフェイスを構築するためのフレームワークです。 この三位一体から、彼は最もユーザーフレンドリーなフレームワークのタイトルを正当に取っています。Vueの開発では、エントリーのしきい値は他の引用された兄弟のしきい値よりも低くなっています。 さらに、それらの中で彼は最年少です。
• 角度-与えられたフレームワークの中で最も複雑なものと考えられ、唯一のものはTypeScript （Javascript言語のアドオン）を必要とします。 多くの場合、大規模なエンタープライズアプリケーションの構築に使用されます。

上記を要約すると、アプリケーションの展開はこのプロセスの進行方法と根本的に異なると結論付けることができます。 しかし、「展開」を昔ながらの方法で実行することを誰も気にしません。 しかし、最初に節約した時間だけの価値はありますか？このパスを選択した開発者が踏まなければならない膨大な数のレーキですか？ 答えはノーだと思います。 これらのツールに慣れるのにもう少し時間を費やしました（そして、現在のプロジェクトで必要かどうかを理解する必要があるため、これ以上必要ありません）。たとえば、環境に依存する幽霊のようなエラーのケースを大幅に減らして、実動サーバー上でのみ現れ、夜間の解析によりサーバーがクラッシュし、なぜ起動しないのか、などなど。