Для предоставления инфраструктуры в облаке AWS в настоящее время мы используем шаблоны формирования облака, вызываемые из ролей ansible, но мы видим, что после увеличения размера инфраструктуры этот код стал неструктурированным или не модульным в GitHub.
На Github есть спагетти с этим кодом без надлежащей структуры, менее читаемые, не легко подбираемые новым специалистом.
В частности, для обеспечения инфраструктуры я вижу, что поддержка кода, написанного в доменные языки, такого как ansible, terraform, cloudformation и т. д., не является хорошей идеей для долгосрочного обслуживания кода в GitHub, потому что для полной (полной) автоматизации вы используете комбинацию этих ТЕХНОЛОГИИ.
Философия заключается в том, что код aws sdk выглядит более структурированным в GitHub, потому что он дает много абстракций, скрывающих детали реализации.
Конечно, код обеспечения так же важен, как и функциональный код, работающий в этой подготовленной инфраструктуре.
Мы уверены, что после перехода с Azure мы будем придерживаться облака AWS.
предметно-ориентированный язык по отношению к языку программирования,
Решает ли подход aws sdk эту проблему? Мы предпочитаем GoLang aws sdk, чтобы любой программист GoLang мог его подобрать.
@Ntwobike terraform — это независимая от облачных вычислений версия cloudformation... пожалуйста, прочтите запрос
Независимость от облака - это только одно, есть и другие отличия, например: вы можете использовать модульную систему, которой нет в CF (стеки да, но не то же самое), однако ваш вопрос не о CF или TF.





Если я правильно понимаю ваш вопрос, вы заявляете, что из-за увеличения размера ваш код Cloud Formation стал неуправляемым, и теперь вы заинтересованы в его определении с помощью AWS SDK, чтобы вы могли использовать лучшие практики программного обеспечения, чтобы сделать код более удобным для обслуживания.
Недостатком AWS SDK по сравнению с декларативным языком является то, что теперь вы несете ответственность за то, чтобы при нажатии кнопки «Выполнить» он не просто создавал новый экземпляр. Например. когда я развертываю машину ec2 с помощью AWS SDK, при следующем запуске этого кода будет развернута новая машина ec2. Cloud Formation сохраняет информацию о том, что и где было развернуто, что упрощает развертывание дополнительных изменений в инфраструктуре и откат изменений.
Я бы порекомендовал вам проверить новый AWS-CDK, который позволяет вам определять код, который в конечном итоге запускается через Cloud Formation. Это позволяет вам писать объекты в стиле OO:
const vpc = new Vpc(this, 'vpc', {
cidr: '10.150.0.0/16',
natGateways: 2,
subnetConfiguration: [
{
name: 'Public',
subnetType: SubnetType.Public,
cidrMask: 20
},
{
name: 'Private',
subnetType: SubnetType.Private,
cidrMask: 22
},
{
name: 'Isolated',
subnetType: SubnetType.Isolated,
cidrMask: 22
}
]
});
К сожалению, Golang пока не поддерживается.
Как скоро поддержка GoLang появится в aws cdk? Есть ли форум aws, где я могу найти ответ?
Я думаю, что поддерживать состояние также сложно с terraform. Не так ли?
Дополнительный... вы предлагаете лучшие практики программного обеспечения для настройки? Ansible — это то, что мы используем сейчас
Я не уверен в дорожной карте AWS-CDK и не уверен, что она общедоступна. Вы можете проверить их Gitter или зарегистрировать проблему на Github. В моей текущей ситуации мне не нужно иметь дело с настройкой программного обеспечения, поскольку мы работаем поверх AWS EKS. Мы не настраиваем вручную виртуальные машины, которые необходимо настроить, поэтому я не могу помочь в этом отношении. Поддерживать состояние в terraform несложно, вы можете легко настроить корзину S3 для поддержания состояния. Сложнее достичь CI/CD, подобного формированию облака, хотя это тоже возможно. Однако Terraform не зависит от облака.
Вы имеете в виду, что формирование облака позволяет использовать CI/CD в отличие от терраформирования? В том смысле, что формирование облака может сопровождаться функциональным кодом... и быть частью сборки jenkins?
Нет, так как Cloud Formation обеспечивает CI/CD, поскольку AWS запускает Cloud Formation сразу после ее развертывания. Terraform — это то, что вы бы развернули сами (или, скорее всего, как часть сборки Jenkins), но у вас нет управляемого конвейера CD, как у облачного формирования AWS. Однако есть много проектов с открытым исходным кодом, которые помогают в этом.
Когда вы говорите, что CloudFormation запоминает состояние? Допустим, если я создаю корневой сертификат ЦС с помощью AWS Certification mgr, используя Шаблон CloudFormation, запоминает ли Cloud Formation состояние? так что повторный запуск этого шаблона не приведет к созданию другого корневого сертификата ЦС.
Можете ли вы порекомендовать мне проекты, о которых вы упомянули?
Да, при запуске шаблона CloudFormation он не будет снова создавать ЦС при повторном запуске. Вы можете проверить, например: runatlantis.io в отношении Terraform CI/CD
Итак, для обработки проблем с состоянием мне нужно использовать aws_cdk вместо aws_sdk или AWS_CLI+ansible.
Да либо CDK, либо Cloud Formation, иначе вы станете ответственным за поддержание состояния.
Готов ли CDK к использованию? Поскольку я вижу из этого обсуждение, требуется больше изменений...
Я имею в виду, что мы используем шаблоны формирования облака для создания ресурсов aws любого типа (CA/EC2/ELB/...). Является ли CDK одинаково мощным инструментом для создания всех этих ресурсов?
Если вы проверите документацию: docs.aws.amazon.com/cdk/api/latest/docs/…, вы увидите, что поддерживается большинство ресурсов.
А терраформ?