「インターネットアーキテクチャ」ソフトウェアアーキテクチャ-Tomcat環境の展開（パート2）

Tomcatの実稼働環境は、アプリケーション用に構成する必要があります。今回は、古いアイアンにとって非常に便利です。実際、実稼働環境で実際に行う必要があることがいくつかあります。古いアイアンから連絡がありました。前述のDockerと多くのデプロイメントは、基本的に運用と保守に関連しており、開発にはほとんど関係していませんか？実際、あなたは私を誤解していました。私の考えでは、アプリケーション環境に関係なく、最終的な展開では、すべての人がそれに完全に精通していることを望んでいます。
ソースコード：https：//github.com/limingios/netFuture/tree/master/tomcat-pro

Tomcatの起動と展開方法（1）

例として実際のプロジェクトを取り上げ、プロジェクトのデプロイメントをセットアップする方法を示します。

＃＃＃＃＃現状

現在、jeakinsとdevopsの人気は徐々に高まっており、より多くの企業が自動的に展開を開始しています。しかし、まだ多くの企業が残っています：段階的なアップグレードとアップグレードするための戦争パッケージ。一緒にプロセスを確認しましょう

インクリメンタルアップグレード
1.プレミスサーバーのjdkとtomcatは、開発と一致している必要があります。
2.フォルダディレクトリを作成し、classやjspなどのファイルを配置します。また、ファイル名とアップグレードする対応するディレクトリの記録を担当するtxtファイルがあります。3
。サービスを停止し、サーバーをパッケージ化してバックアップし、1つずつ置き換えます。アップグレードするコンテンツがまだある場合は、泣く可能性があります。
4.交換後、サービスを開始します。
全体のパッケージはアップグレード
1.に戦争パッケージ
2. Tomcatを停止
3.アップロードをし、元のプログラムのコンテキストディレクトリを置き換え
、元のWARパッケージを削除します。4.
元のコンテキストのディレクトリを削除します。5.
WEB-INFを実行6 /クラス/ app.propertites設定.propertitesディレクトリで適切な設定ファイルを見つけて変更します
。7。Tomcatを起動します。
これの欠点は何ですか？
1.より面倒です
2.リリース失敗
後のロールバック3.Tomcatをアップグレードする必要があり、複数のTomcatを1つずつ実行する必要があります
4. Jeankinsも同じことを行い、最終的にtomcatに分類されます5.Tomcat
も実行時に面倒です構成
6.Tomcatが再起動するときは、binディレクトリーにcatalina.shellも入力する必要があります。
実稼働環境では、複数のアプリケーションを備えた単一のマシンの構成

Tomcatは公開されており、jdkは公開されています。つまり、サービス内のAPP1、APP2、およびAPP3は、このTomcatおよびjdkを参照します。

vagrantを使用して仮想マシンを作成し、仮想マシンのndを設定します。192.168.67.103

vagrant up
su -
#密码 vagrant
vi /etc/resolv.conf
#nameserver 8.8.8.8

jdkをインストールします

実際、私はこのインストール方法が嫌いですが、それがまだ最も主流であるため、古いアイアンに示すために。Dockerのコンテナイメージには感心しますが、通常の操作のトピックに戻り、jdkをインストールします。

yum install -y wget 

wget --no-cookies --no-check-certificate --header "Cookie: gpw_e24=http%3A%2F%2Fwww.oracle.com%2F; oraclelicense=accept-securebackup-cookie" "http://download.oracle.com/otn-pub/java/jdk/8u141-b15/336fa29ff2bb4ef291e347e091f7f4a7/jdk-8u141-linux-x64.tar.gz"
#上边的下载比较慢，建议不通过wget的方式，本地下载后上传上去，我下载了3个多小时，当时正好想看电视剧看了几集
tar -zxvf jdk*
cd jdk*
#获取jdk目录填写到下面JAVA_HOME中
pwd
#追加环境变量
echo "export JAVA_HOME=/root/jdk1.8.0_141" >> /etc/profile
echo "export PATH=$""JAVA_HOME/bin:$""PATH" >> /etc/profile
#执行下面这个才能生效
source /etc/profile
java -version
javac -version

tomcat7をインストールします

ここで必要なTomcatを選択してくださいhttps://mirrors.cnnic.cn/apache/tomcat/

Tomcatをダウンロードしてインストールします

cd ~
#wget tomcat下载的时候很快
wget https://mirrors.cnnic.cn/apache/tomcat/tomcat-7/v7.0.94/bin/apache-tomcat-7.0.94.tar.gz
tar -zxvf apache-tomcat*
#运行下tomcat看能否启用
cd apache-tomcat*
cd bin
./catalina.sh start

サービスプロジェクトディレクトリとシェルスクリプトのデプロイを開始します

1.元のapche-tomcatを作成して、ソフト接続を作成します

cd ~
ln -s jdk1.8.0_141/ jdk
ln -s apache-tomcat-7.0.92/ tomcat

#创建service群，里面可以放很多个tomcat
mkdir services
cd services
#讲tomcat拷贝到service里面一份更改名称叫tomcat-1
cp -r ~/apache-tomcat-7.0.92 tomcat-1
cd tomcat-1
#删除项目中无用的
rm -rf apache-tomcat-7.0.92/ bin BUILDING.txt  CONTRIBUTING.md  LICENSE  NOTICE  README.md  RELEASE-NOTES RUNNING.txt 
cd webapps
rm -rf *

構成シェルスクリプトを開始します

shllスクリプトを作成する

cd ~
cd services/tomcat-1/
vi tomcat.sh
chmod 777 tomcat.sh

スクリプトの内容

#!/bin/bash 
export JAVA_OPTS="-Xms100m -Xmx200m"
export JAVA_HOME=/root/jdk/
export CATALINA_HOME=/root/tomcat
export CATALINA_BASE="`pwd`"

case $1 in
	start)
	$CATALINA_HOME/bin/catalina.sh start
		echo start success!!
	;;
	stop)
		$CATALINA_HOME/bin/catalina.sh stop
		echo stop success!!
	;;
	restart)
	$CATALINA_HOME/bin/catalina.sh stop
		echo stop success!!
		sleep 2 
	$CATALINA_HOME/bin/catalina.sh start
	echo start success!!
	;;
	esac
exit 0

ディレクトリ構造を確認し、tomcatの共通の構成conf、lib、logs、temp、およびwebappsがすべてそこにあることを確認してから、tomcatを起動して、ログがログディレクトリに出力されるかどうかを確認します。

./tomcat start
./tomcat stop

上記のメソッドが実装されています。tomcatとjdkはどちらもパブリックであり、各アプリケーションは、tomcat-1をコピーするだけで、独自の構成セットを持つことができます。内部の構成が完了した後、tomcat-1は実際にはダウンロードしたtomcatですが、一部の公開のものは削除されています。
展開プロセス

1.webappディレクトリにwarパッケージを配置しないでください。2。warディレクトリを
作成します。アップロードされたすべての戦争はこのディレクトリに配置されます。注：アップロードされた戦争パッケージにはバージョン番号が必要
です
。3 。戦争が解凍された後、プロジェクト名-バージョン番号-日付に従って生成されます。4。Appwarはに接続されます。ソフトリンクディレクトリを解凍するための対応する戦争
5.conf / Catalina / lowerで確立されたROOT.xml。warパッケージを解凍して生成されたディレクトリを構成し
ます。6。appwarソフト接続をロールバックする場合は、warディレクトリの下の指定されたプロジェクト解凍ディレクトリに直接変更します
。7。開発中に、svnおよびgitが送信したコードがテストされる場合があります。環境では、app。プロパティを置き換える必要があります。app-confディレクトリを作成できます。プロジェクト内の構成ファイルは、デプロイされるたびに自動的に置き換えられます。公式データベースなどに接続します。

単一のTomcat-1に

cd services
cd tomcat-1
ll

deploy.shを作成します

vi deploy.sh
cat delop.sh
mkdir war
mkdir app-conf

deploy.sh

#!/bin/bash -e

pom_a=$1
pom_v=$2
export work_time=$(date +%Y-%m-%d_%H-%M-%S)
#1. download war, ready env
echo "deploy time: $work_time"

mkdir -p war/
war=war/${pom_a}_${pom_v}.war

deploy_war() {
    
    
        target_d=war/${pom_a}-${pom_v}-$work_time
        target_dir=`pwd`/$target_d
        if [ ! -f "$war" ]; then
                echo "war not exist: $war"
                exit 1
        fi
        unzip -q $war -d $target_dir
        #cp -r `pwd`/app-conf/* $target_dir/WEB-INF/classes/
        rm -f appwar
	ln -sf $target_d appwar

	if [ -f current_deploy.sh ]
		then
			./tomcat.sh stop
			cat current_deploy_dir  > last_deploy		
	fi

        target_ln=`pwd`/appwar
        echo '<?xml version="1.0" encoding="UTF-8" ?>
<Context docBase="'$target_ln'" allowLinking="true">
</Context>' > `pwd`/conf/Catalina/localhost/ROOT.xml
	echo -ne "#!/bin/bash -e\npom_a=${pom_a}\npom_v=${pom_v}" > current_deploy.sh
	echo -ne "${target_d}" > current_deploy_dir
	chmod +x current_deploy.sh
        ./tomcat.sh start
}

deploy_war

テストを実行する

yum install -y unzip zip
yum install -y lrzsz
cd ~/services/tomcat-1/
chmod 777 deploy.sh
cd war
#上传文件例如：com_V1.0.0
rz
cd ..
mkdir -p /root/services/tomcat-1/conf/Catalina/localhost/
# com 是项目名，V1.0.0上传的版本号
./deploy.sh com V1.0.0

最後のtomcat-1ディレクトリ。
1.app-confは構成ファイルです
2.appwarはプロジェクト接続のリリースディレクトリです
3.current_deploy_dir現在公開されているディレクトリ
4.current_deploy.shはpom_aによってdeploy.shで公開されたプロジェクト名を指します
5.warはアップロードされますプロジェクトパス
6.webappsが空です

シェルに基づいてカスタムスタートアップスクリプトを作成し、ワンクリックリリースを実現します。ダウンロードした機能を完了します。

Tomcat実行可能ファイルはプログラムディレクトリから分離されています。（後でTomcatをアップグレードするか、Tomcatを均一に構成すると便利です）
アプリケーションのワンクリック展開とリリース
アプリケーションと構成をすばやくロールバックする
カスタム構成アプリケーション

Tomcat server.xml構成の詳細（2つ）

実際、古いアイアンによって最も構成されているのはcontext.xmlかもしれません

server.xml

<Server>
<Listener /><!-- 监听器 -->
<GlobaNamingResources> <!-- 全局资源 -->
</GlobaNamingResources
<Service> <!-- 服务 用于 绑定 连接器与 Engine -->
<Connector 8080/> <!-- 连接器-->
<Connector 8010 /> <!-- 连接器-->
<Connector 8030/> <!-- 连接器-->

<Engine> <!-- 执行引擎-->
<Logger />
<Realm />
<host "www.tl.com" appBase=""> <!-- 虚拟主机-->
<Logger /> <!-- 日志配置-->
<Context "/luban" path=""/> <!-- 上下文配置-->
</host>
</Engine>
</Service>
</Server>

サーバーアーキテクチャ図

1つのサーバーが複数のサービス
要素に対応できます。主な機能は、1つ以上のコネクタをエンジンに関連付けることです。コネクタはリクエストを受信すると、処理のためにエンジンに配布されます。

ホスト
ホストは仮想ホストを表し、デフォルトではlocalhostが使用され、エンジンで複数のホストを構成できます。
複数の仮想サイト、つまりホストを確立するためのデモンストレーション構成（10分）

コンテキスト
は、アプリケーションのロードディレクトリがpath属性によって指定されていることを示します。相対パスはcatalina_baseディレクトリです。複数のコンテキストを構成できます。また、で見つけることができ $CATALINA_BASE / confに/$ コンテキスト要素を追加 $Sの$ $E$ $/$ $C$ $O$ $N$ $F$ $/$ HOST_NAME / XXX.xml。

要素名	属性	説明
サーバ	港	ポートを指定します。このポートは、Tomcatを閉じる要求をリッスンする役割を果たします。
シャットダウン	ポートに送信されるコマンド文字列を指定します
サービス	名前	サービスの名前を指定します
コネクタ（クライアントとサービス間の接続を表します）	港	サーバー側で作成するポート番号を指定し、このポートでクライアントからの要求をリッスンします
minThread	サーバーがリクエストの処理を開始するときに作成されるスレッドの数
maxThread	リクエストを処理するために作成できるスレッドの最大数
enableLookups	trueの場合、DNSクエリに対してrequest.getRemoteHost（）を呼び出すことで、リモートクライアントの実際のホスト名を取得できます。falseの場合、DNSクエリは実行されませんが、そのIPアドレスが返されます。
redirectPort	サーバーがhttp要求を処理しているときにSSL送信要求を受信した後にリダイレクトされるポート番号を指定します
acceptCount	リクエストの処理に使用できるすべてのスレッドが使用されたときに処理キューに入れることができるリクエストの数を指定します。この数を超えるリクエストは処理されません。
connectionTimeout	タイムアウト期間を指定します（ミリ秒単位）
エンジン（指定されたサービスの要求ハンドラーを表し、Connectorからの要求を受信して処理します）	defaultHost	要求を処理するためのデフォルトのホスト名を指定します。これは、少なくともホスト要素の1つのname属性値と同じです。
コンテキスト（Webアプリケーション、通常はWARファイルを表します。WARに関する特定の情報についてはサーブレット仕様を参照してください）	docBase	アプリケーションのパスまたはWARファイルが保存されているパス
pathは、このWebアプリケーションのURLのプレフィックスを表すため、要求されたURLはhttp：// localhost：8080 / path / ****です。
リロード可能	この属性は非常に重要です。trueの場合、tomcatはアプリケーションの/ WEB-INF / libおよび/ WEB-INF / classesディレクトリの変更を自動的に検出し、新しいアプリケーションを自動的にロードします。再起動せずに実行できます。 Tomcat変更アプリケーション
ホスト（仮想ホストを表します）	名前	ホスト名を指定します
appBase	アプリケーションの基本ディレクトリ、つまりアプリケーションが保存されているディレクトリ
unpackWARs	trueの場合、tomcatは自動的にWARファイルを解凍します。そうでない場合、tomcatはアプリケーションを解凍してWARファイルから直接実行しません。
ロガー（ログ、デバッグ、およびエラー情報を表します）	クラス名	ロガーが使用するクラス名を指定します。このクラスは、org.apache.catalina.Loggerインターフェースを実装する必要があります。
プレフィックス	ログファイルのプレフィックスを指定します
サフィックス	ログファイルのサフィックスを指定します
タイムスタンプ	trueの場合、次の例のように、ログファイル名に時間を追加する必要があります。localhost_log.001-10-04.txt
レルム（ユーザー名、パスワード、およびロールを格納するデータベースを表します）	クラス名	Realmで使用されるクラス名を指定します。このクラスはorg.apache.catalina.Realmインターフェースを実装する必要があります。
バルブ（ロガーと同様の機能、その接頭辞と接尾辞の属性の解釈はロガーと同じです）	クラス名	Valveが使用するクラス名を指定します。たとえば、org.apache.catalina.valves.AccessLogValveクラスを使用して、アプリケーションのアクセス情報を記録します。
ディレクトリ	ログファイルの保存場所を指定します
パターン	2つの値があります。共通のメソッドは、リモートホスト名またはIPアドレス、ユーザー名、日付、最初の行で要求された文字列、HTTP応答コード、および送信されたバイト数を記録します。組み合わせた方法は、一般的な方法よりも多くの値を記録します

Tomcatクラスター

Tomcatセッションマネージャー

StandardManager

Tomcat6のデフォルトのセッションマネージャは、非クラスタ環境で単一のTomcatインスタンスのセッションを管理するために使用されます。Tomcatがシャットダウンすると、これらのセッションに関連するデータがディスク上のSESSION.serというファイルに書き込まれ、このファイルは次回Tomcatが起動されたときに読み取られます。

PersistentManager

セッションが長時間アイドル状態になると、スワップセッションオブジェクトに書き込まれます。これは、メモリリソースが不足しているアプリケーション環境でより役立ちます。

DeltaManager

Tomcatクラスターのセッションマネージャー。変更されたセッションデータをクラスター内の他のノードに同期することでセッションレプリケーションを実装します。この実装は、すべてのセッションの変更をクラスター内の各ノードに同期します。また、クラスター環境で最も一般的に使用される実装でもあります。

バックアップマネージャ

Tomcatクラスターで使用されるセッションマネージャーは、ノードのセッション変更がすべてのノードではなくクラスター内の別のノードにのみ同期されるという点でDeltaManagerとは異なります。

PS：今回、Tomcatを構成する方法がたくさんあるかどうかを見てきました。実際、多くの人が現在のプロジェクトに満足していて、不平を言うことを意味し、技術的な手段で既存の鈍い技術を変更したくないのです。実はとても恥ずかしいです。

「インターネットアーキテクチャ」ソフトウェアアーキテクチャ-Tomcat環境の展開（パート2）

Tomcatの起動と展開方法（1）

Tomcat server.xml構成の詳細（2つ）

Tomcatクラスター

おすすめ