У меня есть два сервера Elastic Beanstalk для одной и той же кодовой базы. Один постановочный, другой постановочный.
Я пытаюсь использовать условное container_command
для создания crontab, который будет работать только в рабочей среде. Эти условные операторы отлично работают для обычных commands
, но, кажется, всегда оценивается как true для container_commands
. Однако, согласно другим сообщениям и примерам SO, они должны работать одинаково для обоих типов команд.
Вот что я пытаюсь сделать:
container_commands:
01_activate_cronjob:
test: '[ "${BEANSTALK_ENVIRONMENT}" == "production" ]'
command: "cat .ebextensions/my_cron_file > /etc/cron.d/my_cron_file && chmod 644 /etc/cron.d/my_cron_file"
leader_only: true
BEANSTALK_ENVIRONMENT
— это переменная Elastic Beanstalk, установленная в моих конфигурациях beanstalk, и я подтвердил, что echo $BEANSTALK_ENVIRONMENT
выводит «производство» и «постановка» соответственно.
Я также пробовал эту test
строку:
test: test $BEANSTALK_ENVIRONMENT == production
Кроме того, я проверил правильность этих тестовых команд в терминале.
test $BEANSTALK_ENVIRONMENT == production && echo yes || echo no
# outputs "yes" on the production server and "no" on the staging server
Я знаю, что могу взломать/исправить это, вставив условный оператор внутри части command
; однако, как я уже сказал ранее, все в Интернете указывает на то, что это должно работать, поэтому я в тупике.
В соответствии с Документы AWS вы можете использовать только один из test
и leader_only
, и если вы используете оба, leader_only
выиграет:
A command can be leader-only or have a test, but not both (leader_only takes precedence).
Я бы еще раз подумал, нужен ли вам leader_only
в вашем конкретном случае использования.
Вау, хорошая находка, ты прав. Мне не обязательно нужен
leader_only
прямо сейчас, поэтому я могу удалить его, но я буду помнить об этом.