efekarakus

Dynamically populating manifests from AWS tags

Motivation

We’d like to re-use the from_tags pattern eventually for all of our imports to dynamically populate fields. The goal is to make easy to add a from_tags field to our other types.

Examples

efekarakus

Today, users can associate new AWS resources to a single microservice through service addons [1]. However, there are resources such as Application Load Balancers or Elastic File Systems that are designed to be shared by multiple consumers. Today, Copilot provides a managed experience for sharable resources via the manifest file with the http, alias, or efs fields.

This document proposes a way for users to create their own sharable resources between microservices so that they are not blocked on the Copilot team to support the integration.

Target use cases

AWS resources that are meant to be shared typically (and ideally should) support a “decoupling layer”.

efekarakus

Parameters:
  App:
    Type: String
    Description: Your application's name.
  Env:
    Type: String
    Description: The environment name your service, job, or workflow is being deployed to.
  Name:
    Type: String
    Description: The name of the service, job, or workflow being deployed.

efekarakus

Parameters:
  App:
    Type: String
    Description: Your application's name.
  Env:
    Type: String
    Description: The environment name your service, job, or workflow is being deployed to.
  Name:
    Type: String
    Description: The name of the service, job, or workflow being deployed.

efekarakus

AWSTemplateFormatVersion: '2010-09-09'
Description: 'CloudFormation Template to create Aurora Postgresql Cluster DB Instance'

###############################################################################
# Parameters 
###############################################################################   

Parameters:

  ParentVPCStack:

efekarakus

Parameters:
  App:
    Type: String
    Description: Your application's name.
  Env:
    Type: String
    Description: The environment name your service, job, or workflow is being deployed to.
  Name:
    Type: String
    Description: The name of the service, job, or workflow being deployed.

efekarakus

[Container] 2019/04/26 16:56:32 Running command make integ-test 
Installing dependencies... 
go get github.com/wadey/gocovmerge 
Building ecs-cli.test... 
env -i PATH=$PATH GOPATH=$GOPATH GOROOT=$GOROOT GOCACHE=$GOCACHE \ 
    go test -coverpkg ./ecs-cli/modules/... -c -tags testrunmain -o ./bin/local/ecs-cli.test ./ecs-cli 
Running integration tests... 
go test -tags integ ./ecs-cli/integ/e2e/... 
ok      github.com/aws/amazon-ecs-cli/ecs-cli/integ/e2e 350.161s 
# Our integration tests generate a separate coverage file for each CLI command. 

efekarakus

// Before
function recordMetricOnCompletion(metricName, promise) {
  const metric = Metric.newTimedMetric(metricName);
  
  return promise
    .then(values => {
      metric.emitSuccess();
      return Promise.resolve(values);
    })
    .catch(reason => {

efekarakus

function getRecordedPromise(metricName) {
 const metric = Metric.newTimedMetric(metricName);
  
 return (promise) => {
  return promise
    .then(values => {
      metric.emitSuccess();
      return Promise.resolve(values);
    })
   .catch(reason => {

efekarakus

function recordMetricOnCompletion(metricName, promise) {
  const metric = Metric.newTimedMetric(metricName);
  
  return promise
    .then(values => {
      metric.emitSuccess();
      return Promise.resolve(values);
    })
    .catch(reason => {
      metric.emitFailure();