Ссылка Существующие выходы отображения облачной информации в серверной системе

Мы оцениваем, использовать ли Serverless для некоторых наших новых инфраструктур приложений AWS. Мы в значительной степени используем Cloudformation (развернутый Ansible), поэтому нам нужно будет иметь возможность четко ссылаться на выходы существующих стеков Cloudобласти - одним из непосредственных примеров было бы получение идентификаторов подсети нашей существующей сетевой инфраструктуры AWS для использования с помощью лямбда-функции ,Ссылка Существующие выходы отображения облачной информации в серверной системе

После многократного просмотра, я не видел готового способа сделать это. Наши существующие стеки Cloudformation называются такими, что если бы я мог просто указать имя стека и желаемую выходную переменную, я мог бы надежно получить желаемые выходы в разных средах. Одно из возможных решений, которое я вижу, - это вытащить переменные с помощью aws cli и передать их как переменные окружения безсерверным, но я хотел бы, если бы это было возможно, более чистым способом.

источник

2016-12-05 rumdrums

Просьба уточнить, относится ли ваш вопрос к AWS [серверной модели приложений] (https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md) (SAM) или [Сервер без сервера] (https://serverless.com/). – wjordan

Если Serverless Framework позволяет использовать Intrinsic Functions внутри ваших шаблонов CloudFormation, вы можете create cross-stack references в шаблоне CloudFormation по exporting stack output values из одного стека (используя Exports свойство в разделе Outputs), и используя Fn::ImportValue внутреннюю функцию в другой стек для укажите экспортируемую стоимость.

источник

2017-01-09 21:40:00 wjordan

Это, безусловно, лучший ответ. Мы избегали ссылок на несколько стеков 1) b/c, они существовали только до недавнего времени, и 2) мне нравится ослабление связи, которое происходит от явной передачи выходов одного стека в качестве параметров в другой стек. Я думаю, что мы решили, что «sls» немного ограничен для наших нужд, но это определенно было бы возможным, если бы мы использовали его. – rumdrums

Самый простой способ, с помощью которого я могу обращаться с вашим примером, - использовать лямбда boto3 для звонка boto3.client('cloudformation', region_name=*specified region*).describe_stacks(StackName=*specified stack*)['Stacks']. Этот список содержит все стеки, которые соответствуют указанному StackName, если вся ваша сетевая инфраструктура разделяет подмножество их имен, вы можете перечислить все из них, указав StackName на эту подстроку. Каждый объект Stack содержит блок 'Outputs'. См. here.

Если вы хотите разоблачить это для удобного использования из любого места, вы можете подключить метод GET Gateway GET к лямбда и выставить его в HTML-форму.

источник

2016-12-05 21:53:11 asdf

Спасибо за ответ. Проблема, которую я вижу в этом подходе, заключается в том, что в идеале у меня бы были значения переменных * до того, как я даже разблокирую функцию Lambda. Поскольку для развертывания функций необходимо подключиться к экземпляру RDS, им нужны идентификаторы подсети, чтобы создать эластичный сетевой интерфейс и получить доступ к нашей сети. – rumdrums

@rumdrums Есть ли причина, по которой вы не можете найти значения перед подключением к RDS? – asdf

Я понимаю, что когда я создаю лямбда-функцию, мне нужно дать ей идентификаторы подсети, к которой она будет подключаться, как в параметре VpcConfig, описанном здесь [http://docs.aws.amazon.com/AWSCloudFormation /latest/UserGuide/aws-properties-lambda-function-vpcconfig.html). Я не думал, что возможно, чтобы функция лямбда получила идентификаторы подсети после того, как она уже развернута. – rumdrums

Ссылка Существующие выходы отображения облачной информации в серверной системе

ответ

Смежные вопросы