.NETがDocker-Docker統合Cronに遭遇した場合.NETCore(ConsoleApp)プログラム.md
5966 ワード
プロジェクトのDockerサポートの構成
VSのDockerの構成については、相変わらずくだらないことを繰り返しています.プロジェクトにDockerサポートを追加し、VS 2015はDocker for VSプラグインを直接使用することができ、VS 2017はインストール時にコンテナサポートを選択する.VSコンテナサポートを構成したら、項目を右クリックし、メニューを追加すると
Linuxでcronタイミングで実行.NETCore App
1つの穴.
実行できないに違いありませんが、
(root)CMDOUT(/bin/sh:dotnet:コマンドが見つかりません)
くぼみを這う
.NetCoreアプリケーションの実行を支援するには、次のスクリプトが必要です.
いくつかの既知の制限は、アプリケーションディレクトリに
cron出力ログで
このファイルを
注意rundotnet.shの権限を変更して実行権限を持たせる
もう1つの方法は、アプリケーションを直接実行可能プログラムとしてパブリッシュすることです.親測はVS 2017リリース.NetCore App(.NETCoreバージョン1.0.4)を使用し、.NetCore SDK 1.0.3がインストールされているLinuxで以下のcron構成を使用して正常に実行できます.
同様にyour.appファイルの実行権限を付与する必要があります
VS 2015リリース.NetCore App(.NETCoreバージョン1.0.0)は、.NetCore SDK 1.0.1がインストールされているLinuxでは正常に実行できません.
Dockerへの統合
目の先の園友がなぜここに
ファイルを作成したら出力ディレクトリにパブリッシュするように構成し、dotnet pulish後にdocker buildで使用できるようにします.
次に、docker containerの実行エントリとして使用されるファイル
最後の行は、システムログ(syslogでsyslog)とdotnet appの出力(cron.logでは、前に出力のリダイレクトが追加されていることを前提として)をそれぞれ出力します.
VSで作成したDockerfileファイルの内容を変更すると、次のようになります.
Dockerfileではベースコンテナにcronとrsyslogを追加し、debian/ubuntu(dotnet公式ミラーのベースシステム)cronではrsyslogでログを出力する必要があります.
最終出力ディレクトリには、次のファイルが含まれます.
次のコマンドpublishプロジェクトを使用します.
publishのファイルをdockerがインストールされている環境に転送し、dockerイメージを生成する準備をします.
Dockerイメージを生成し、Containerを実行
古いイメージのクリーンアップを含む実行スクリプトをbuildhelper.shに統合します.
このファイルをパブリケーションディレクトリに出力するように設定します(Linuxでは実行権限を付与します).
コンテナが実行されるとcontainerのbashに接続して実行状況を表示できます
テストのたびにDocker Imageがapt-getインストールcronを行うのは面倒だと感じたら、cronとrsyslogを含むミラーを作成し、この例のベースミラーとして使用することができます.(ブロガーが提供したこれらに従って基本的には成功できます)
ヒント
すべてのshellスクリプトファイル(xxx.sh)は、UTF 8形式の場合、BOMのないUTF 8を使用してエンコードされます.またはASCIIを使用します.そうしないとbashは正常に動作しません.ボタンでBOMを除去する方法:
crontabは改行を処理することが重要です.そうしないと、linuxでは必要な空の行が認識されず、正規のロードができません.
rsyslogdの次のエラープロンプトは安全に無視できます:rsyslogd:imklog:cannotopen kernel log(/proc/kmsg):Operation not permitted.エラー:Could not open output pipe'/dev/xconsole':No such file or directory影響の有無はしばらく分かりません(rsyslogの作業に影響はありません)
タイミングタスク時間タイミングタスクについては、従来使用していたベースミラー
Dockerでこのようなタイミングタスクを実行する必要があるのかと疑問に思う子供もいるかもしれませんが、主にDockerが最も重要なのはやはり異なる下層システムの違いを遮断することです.ついでに異なるアプリケーションのタイミングタスクを分離することができます.本文も必要な子供靴の参考にする方法を提供します.
VSのDockerの構成については、相変わらずくだらないことを繰り返しています.プロジェクトにDockerサポートを追加し、VS 2015はDocker for VSプラグインを直接使用することができ、VS 2017はインストール時にコンテナサポートを選択する.VSコンテナサポートを構成したら、項目を右クリックし、メニューを追加すると
Docker Support
オプションが表示されます.VS 2015のDocker for VSプラグインは、package.jsonのpublishOptions
にDockerfileを追加します.これにより、Dockerfileを含むImageの生成に直接使用できる出力が得られる.VS 2017では、「追加-Dockerサポート」メニューを使用して追加したDockerfileファイルが出力ディレクトリに自動的に出力されるようには設定されていません.Dockerfileを選択して属性を右クリックし、「属性」タブで「新しい場合はコピー」を選択します.Linuxでcronタイミングで実行.NETCore App
1つの穴.
dotnet publish
で直接次の方法でタスクを追加した場合:crontab -e
実行できないに違いありませんが、
*/2 * * * * dotnet /publish/your.app.dll #2 ,
で次のエラー出力(CentOS)が表示されます.(root)CMDOUT(/bin/sh:dotnet:コマンドが見つかりません)
くぼみを這う
.NetCoreアプリケーションの実行を支援するには、次のスクリプトが必要です.
#!/bin/sh
export PATH=$PATH:/publish:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin
cd /publish
dotnet your.app.dll >> /var/log/cron.log 2>&1 # ( ), `/var/log/cron`
exit;
EOF
いくつかの既知の制限は、アプリケーションディレクトリに
tail -f /var/log/cron
を含めることはできません.cron出力ログで
.
というエラーが発生しないように、指定したファイルにリダイレクトすることをお勧めします.このファイルを
No MTA installed, discarding output
に保存し、設定をパブリッシュファイルに出力します.このファイルは、.NetCoreプログラムを実行するためにcronによってタイミングが呼び出されます.rundotnet.sh
を使用してcronタスクを変更するには、次のようにします(追加後、crontab -e
を使用して追加結果を検証できます).crontab -l
注意rundotnet.shの権限を変更して実行権限を持たせる
もう1つの方法は、アプリケーションを直接実行可能プログラムとしてパブリッシュすることです.親測はVS 2017リリース.NetCore App(.NETCoreバージョン1.0.4)を使用し、.NetCore SDK 1.0.3がインストールされているLinuxで以下のcron構成を使用して正常に実行できます.
*/2 * * * * /publish/rundotnet.sh
同様にyour.appファイルの実行権限を付与する必要があります
VS 2015リリース.NetCore App(.NETCoreバージョン1.0.0)は、.NetCore SDK 1.0.1がインストールされているLinuxでは正常に実行できません.
Dockerへの統合
*/2 * * * * /publish/your.app
という名前のファイルを作成してcronコマンドを保存します.内容は、crontab
を使用して追加したタスクです.*/2 * * * root /publish/rundotnet.sh # root ,
# cron
目の先の園友がなぜここに
crontab -e
というユーザー名があるのかを発見したかもしれないが、前文のテストはRedHat系(CentOS 7)で行われた.マイクロソフトの.NETCore Docker IamgeはDebian系システムに基づいており、ここにはユーザー名が必要です.そうしないと、「crontabファイルフォーマットが不正」のようなエラーが表示されます.ファイルを作成したら出力ディレクトリにパブリッシュするように構成し、dotnet pulish後にdocker buildで使用できるようにします.
次に、docker containerの実行エントリとして使用されるファイル
root
を追加する.rsyslogd
cron
touch /var/log/cron.log
tail -F /var/log/syslog /var/log/cron.log
最後の行は、システムログ(syslogでsyslog)とdotnet appの出力(cron.logでは、前に出力のリダイレクトが追加されていることを前提として)をそれぞれ出力します.
runcron.sh
コマンドはcontainerの一貫した実行を保証し、終了しなくてもdockerのtail
パラメータで容器の運転を制御することができます.VSで作成したDockerfileファイルの内容を変更すると、次のようになります.
FROM microsoft/dotnet:1.0-runtime
COPY . /publish
WORKDIR /publish
# cron
# microsoft/dotnet:1.0-runtime cron, , rsyslog
RUN apt-get update \
&& apt-get install -y --no-install-recommends \
cron \
rsyslog \
&& rm -rf /var/lib/apt/lists/*
# crontab cron
ADD crontab /etc/cron.d/dotnet-cron
# crontab (rw/r/r)
RUN chmod 0644 /etc/cron.d/dotnet-cron
# , tail
RUN touch /var/log/cron.log
# runcron.sh rundotnet.sh
RUN chmod +x /publish/rundotnet.sh
RUN chmod +x /publish/runcron.sh
# runcron.sh
CMD ["bash","/publish/runcron.sh"]
Dockerfileではベースコンテナにcronとrsyslogを追加し、debian/ubuntu(dotnet公式ミラーのベースシステム)cronではrsyslogでログを出力する必要があります.
最終出力ディレクトリには、次のファイルが含まれます.
"appsettings.json",
"Dockerfile",
"crontab",
"rundotnet.sh",
"runcron.sh"
次のコマンドpublishプロジェクトを使用します.
dotnet publish --framework netcoreapp1.0 --configuration release --output publish
publishのファイルをdockerがインストールされている環境に転送し、dockerイメージを生成する準備をします.
Dockerイメージを生成し、Containerを実行
古いイメージのクリーンアップを含む実行スクリプトをbuildhelper.shに統合します.
#!/bin/bash
contName=$1
contName=${contName:="containerName"}
imagName=$2
imagName=${imagName:="orgname/projname:tag"}
docker stop ${contName}
docker rm -f ${contName}
docker rmi ${imagName}
docker ps -a
docker images
sudo docker build --rm -t orgname/projname:tag .
sudo docker run --name containerName -it orgname/projname:tag
このファイルをパブリケーションディレクトリに出力するように設定します(Linuxでは実行権限を付与します).
コンテナが実行されるとcontainerのbashに接続して実行状況を表示できます
docker exec -it containerName /bin/bash
テストのたびにDocker Imageがapt-getインストールcronを行うのは面倒だと感じたら、cronとrsyslogを含むミラーを作成し、この例のベースミラーとして使用することができます.(ブロガーが提供したこれらに従って基本的には成功できます)
ヒント
すべてのshellスクリプトファイル(xxx.sh)は、UTF 8形式の場合、BOMのないUTF 8を使用してエンコードされます.またはASCIIを使用します.そうしないとbashは正常に動作しません.ボタンでBOMを除去する方法:
--restart=always
Windowsでshファイルを編集した場合、linux種でエラーが発生する可能性があります:「/bin/bash^M:破損した解釈器:そのファイルまたはディレクトリがありません」これは、Windowsがgrep -r -I -l $'^\xEF\xBB\xBF' /path | xargs sed -i 's/^\xEF\xBB\xBF//g'
、Linuxが
\r
であり、
が^Mと表示されるためです.sed -i 's/\r$//g' crontab
sed -i 's/\r$//g' buildhelper.sh
sed -i 's/\r$//g' rundotnet.sh
sed -i 's/\r$//g' runcron.sh
crontabは改行を処理することが重要です.そうしないと、linuxでは必要な空の行が認識されず、正規のロードができません.
rsyslogdの次のエラープロンプトは安全に無視できます:rsyslogd:imklog:cannotopen kernel log(/proc/kmsg):Operation not permitted.エラー:Could not open output pipe'/dev/xconsole':No such file or directory影響の有無はしばらく分かりません(rsyslogの作業に影響はありません)
タイミングタスク時間タイミングタスクについては、従来使用していたベースミラー
\r
のタイムゾーンがUTC時間であることに注意し、我々UTC+8の場所についてはcronを構成する時間に8時間を加える.ミラーを生成する際にタイムゾーンを直接修正し、Dockerfileにsed -i 's/\r$//g' filename
を加えるDockerでこのようなタイミングタスクを実行する必要があるのかと疑問に思う子供もいるかもしれませんが、主にDockerが最も重要なのはやはり異なる下層システムの違いを遮断することです.ついでに異なるアプリケーションのタイミングタスクを分離することができます.本文も必要な子供靴の参考にする方法を提供します.