My Compute Engine vm при развертывании запускает сценарий запуска. Кажется, все работает нормально, но в сценарии запуска есть одна команда, которой, как мне кажется, нет.
Я запускаю команду
apt-get update && apt-get upgrade -y
Это должно установить самые новые версии всех пакетов (верно?)
Когда я делаю это вручную, это работает, но на это уходит много времени. Если я позволю скрипту сделать это, я не увижу никаких выходных данных при подключении по ssh, поэтому я должен предположить, что он все еще работает. Есть ли способ узнать, работает ли он по-прежнему и завершился ли он?
Это сценарий:
#! /bin/bash
file="/var/www/check.txt"
if [ -e $file ]
then
apt-get update && apt-get upgrade -y
git -C /var/www/html pull https://xxxxxx:xxxxxxxx@bitbucket.org/xxxxxx/xxxxx.git
else
apt-get update
apt-get install apache2 php libapache2-mod-php php-mcrypt php-mysql mysql-client -y
a2dismod autoindex
service apache2 restart
cat <<EOF > /etc/apache2/mods-enabled/dir.conf
<IfModule mod_dir.c>
DirectoryIndex index.php index.cgi index.pl index.html index.xhtml index.htm
</IfModule>
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
EOF
rm -rf /var/www/html
git clone https://xxxxxx:xxxxxx@bitbucket.org/xxxxxx/xxxxx.git /var/www/html/
cat <<EOF > /etc/apache2/sites-available/xxxxx.conf
<VirtualHost *:80>
ServerName xxxxxx.com
ServerAlias www.xxxxxx.com
ServerAdmin webmaster@xxxxx.xx
DocumentRoot /var/www/html/wwwroot
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
EOF
cat <<EOF > /etc/apache2/sites-available/020-xxxxx_xxxx.conf
<VirtualHost *:80>
ServerName xxxx.xxxxx.xxx
ServerAlias xxxx
ServerAdmin webmaster@xxxxx.xx
DocumentRoot /var/www/html/xxxxx
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
EOF
cat <<EOF > /var/www/html/wwwroot/.htaccess
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
EOF
sed -i 's/AllowOverride None/AllowOverride All/g' /etc/apache2/apache2.conf
wget https://dl.google.com/cloudsql/cloud_sql_proxy.linux.amd64 -O cloud_sql_proxy
chmod +x cloud_sql_proxy
mkdir /cloudsql; sudo chmod 777 /cloudsql
./cloud_sql_proxy -dir=/cloudsql &
#rm /var/www/html/wwwroot/xxxxx/xxxxxx.php
#temporary for testing.
cat <<'EOF' > /var/www/html/wwwroot/includes/xxxxx.xxxx
<?php
error_reporting(E_ALL);
ini_set('display_errors', 1);
$username = "xxxxxx";
$password = "xxxxx";
$host = "/cloudsql/snappy-gantry-xxxxx:europe-west1:db1";
$dbname = "xxxxx";
setlocale(LC_ALL, 'nld_nld');
$options = array(PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES utf8');
try {
$db = new PDO("mysql:unix_socket={$host};dbname={$dbname};charset=utf8", $username, $password, $options);
$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$db->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_ASSOC);
} catch (PDOException $ex) {
die("Failed to connect to the database: " . $ex->getMessage());
}
if (session_status() == PHP_SESSION_NONE) {
session_start();
}
EOF
a2dissite 000-default
a2ensite 010-xxxxx_main
a2ensite 020-xxxx_help
a2enmod rewrite
service apache2 restart
apt-get update && apt-get upgrade -y
sudo cat <<EOF > /var/www/check.txt
aanwezig!
EOF
fi
Выходные данные сценария запуска экземпляров Google Cloud Compute Engine записываются в один из следующих лог-файлы в зависимости от дистрибутива Linux экземпляра:
Если по какой-то причине вы хотите сохранить обновления скрипта, вы можете перенаправить вывод в файл и загрузить идентификатор в Google Storage. Например:
...
$ command >> output
$ command >> output
$ gsutil cp output gs://yourbucketname/output
$ command >> output
...
$ command >> output
$ gsutil cp output gs://yourbucketname/output
$ ...
Обратите внимание, что вы также можете перенаправить стандартную ошибку с помощью '2>>
'в файл и тоже загрузите его.
РЕДАКТИРОВАТЬ: Я забыл ответить на один из ваших вопросов. Да, вы можете проверить, выполняется ли команда; поскольку с точки зрения операционной системы эти команды являются обычными процессами, вы сможете проверить их выполнение:
$ ps -aux
Например, я получил этот вывод с sleep
как сценарий запуска
root 691 0.0 0.0 5840 696 ? S 14:45 0:00 sleep 30
grep запуск-скрипт / var / журнал / системный журнал
Для RHEL и CentOS вы также можете использовать команду journalctl
$ journalctl
или если вы хотите следить за журналами в реальном времени, когда ваш сценарий запуска выполняет вас, вы можете использовать параметр -f:
$ journalctl -f