У меня WebServer говорит, что WS-1, а сервер NFS говорит о настройке NFS-1 на AWS. WS-1 управляется эластичным балансировщиком нагрузки, а также автоматически масштабируется. Он также имеет EBS, установленную на / var / www, который содержит весь код приложения.
Если во время автомасштабирования будет запущен другой WS-X, будет ли клонирован и прикреплен к нему EBS, смонтированный в / var / www? Если нет, то какие у меня варианты, помимо размещения кода на корневом томе EBS?
Доступ внутри NFS определяется на основе IP, например 10.0.0.1/32(rw, ...). Во время автомасштабирования будет запущено больше экземпляров, как я могу разрешить им подключиться к серверу NFS и смонтировать общий каталог? Я не хочу предоставлять доступ к частной IP-подсети с использованием NFS, в то время как на уровне группы безопасности я дал доступ к серверу NFS для 0.0.0.0/0. Сервер NFS использует фиксированные порты, например 111, 2049, 4000-4002.
При увеличении масштаба том EBS и его данные не будут «клонированы». Чтобы иметь такое поведение, вам нужно автоматизировать его при загрузке.
Другой метод, зависящий от объема данных в EBS, - это загрузить их с S3.
С помощью группы безопасности вы можете разрешить любому серверу в app_security_group иметь доступ к любому серверу в nfs_server_group. Это позволит вам динамически обновлять группы безопасности.
Надеюсь, это имеет смысл.
Ваш экземпляр будет «клонирован» только в том случае, если у вас есть недавний AMI (образ машины Amazon), созданный для этого экземпляра. Вероятно, с тех пор, как был сделан этот снимок, в вашей файловой системе произойдут некоторые изменения, поэтому рекомендуется использовать Пользовательские данные AWS для создания сценария Bash / CloudInit, который будет запускать обновление в областях, которые будут изменены, например кодовая база, медиа и т. д.
Варианты обновления определенных областей могут быть одним из следующих (перечисление плюсов и минусов):
Вот пример сценария начальной загрузки, который вы можете применить к своей конфигурации запуска, чтобы запустить ее для динамического выполнения задач начальной загрузки. Обратите внимание, что сценарии userdata выполняются от имени пользователя root.
#!/bin/bash
# Update your packages
yum update -y
# Get/execute bootstrapping
cd /tmp
git clone ssh://your-git-server/bootstrapping-repo.git
chmod +x /tmp/your-repo/bootstrapping.sh
# Execute it
/tmp/your-repo/bootstrapping.sh
# Remove the bootstrapping script remnants
rm -rf /tmp/your-repo
Этот метод позволяет вам гибко обновлять ваше «начальное репо» так часто, как вам нужно, без необходимости регулярно создавать новые AMI.
В качестве фона я использую S3 в своих пользовательских данных для получения соответствующих ключей SSH, файлов хоста и т. Д. И Git для репозитория начальной загрузки.
Также неплохо поддерживать ваши AMI в актуальном состоянии как можно чаще и сохранять их в конфигурации запуска, чтобы новые запускаемые экземпляры не тратили слишком много времени на обновление. Делаете ли вы это время от времени вручную или пишете скрипт для этого через API или CLI - решать вам.
К вашему сведению: вывод пользовательских данных и последующих скриптов, которые вызываются при запуске экземпляра, будут записаны в файл /var/log/cloud-init-output.log