-
Notifications
You must be signed in to change notification settings - Fork 33
general questions around integration with existing pipeline #1
Description
Hi!
I love seeing this here as we've been building out our own custom pipeline with jenkins. Are there further setups available that would support the following?
external vs internal LB's depending on service type
blue/green/canary
zero downtime swaps between targets ( no lost connections )
scaling
I use ECS launch types right now as I have fine grained control over what we would like, vpc access etc.
I've attempted to combine the two solutions. The current deployment pipeline deploys the following logical items (based on internal vs external conditions):
ecs-service-bg-common-isolated.yml
ExternalCommonDNS:
Type: AWS::Route53::RecordSetGroup
ExternalCommonInActiveDNS:
Type: AWS::Route53::RecordSetGroup
InternalCommonDNS:
Type: AWS::Route53::RecordSetGroup
InternalCommonInActiveDNS:
Type: AWS::Route53::RecordSetGroup
LoadBalancerSecurityGroup:
Type: AWS::EC2::SecurityGroup
ExternalFacingLoadBalancer:
Type: AWS::ElasticLoadBalancingV2::LoadBalancer
ExternalFacingLoadBalancerHTTPListener:
Type: AWS::ElasticLoadBalancingV2::Listener
ExternalFacingLoadBalancerHTTPSListener:
Type: AWS::ElasticLoadBalancingV2::Listener
InternalLoadBalancer:
Type: AWS::ElasticLoadBalancingV2::LoadBalancer
InternalLoadBalancerHTTPListener:
Type: AWS::ElasticLoadBalancingV2::Listener
InternalLoadBalancerHTTPSListener:
Type: AWS::ElasticLoadBalancingV2::Listener
BlueTargetGroup:
Type: AWS::ElasticLoadBalancingV2::TargetGroup
GreenTargetGroup:
Type: AWS::ElasticLoadBalancingV2::TargetGroup
ExternalHTTPDefaultRedirect:
Type: AWS::ElasticLoadBalancingV2::ListenerRule
InternalHTTPDefaultRedirect:
Type: AWS::ElasticLoadBalancingV2::ListenerRule
Active dns is the main route. Inactive means same domain, just inactive- stuck on front. I use this to run some tests against as part of the bluegreen but in this case I'm doing DNS swaps, not target groups.
For the actual service here's my setup:
ecs-service.yml
TaskRole:
Type: AWS::IAM::Role
Service:
Type: AWS::ECS::Service
BlueTaskDefinition:
Type: AWS::ECS::TaskDefinition
ScalingRole:
Type: AWS::IAM::Role
ScalableTarget:
Type: AWS::ApplicationAutoScaling::ScalableTarget
CPUUtilizationScalingPolicy:
Type: AWS::ApplicationAutoScaling::ScalingPolicy
MemoryUtilizationScalingPolicy:
Type: AWS::ApplicationAutoScaling::ScalingPolicy
RequestsScalingPolicy:
Type: AWS::ApplicationAutoScaling::ScalingPolicy
RequestsAlarm:
Type: AWS::CloudWatch::Alarm
This is about as far as I got with the merged setup; as it seems I can't do autoscaling with TaskSet and ECS as the launch type. Cloudformation was giving internal errors but no message.
Example diagram:
I've scrapped the idea of the DNS swap and stopped doing that so for right now; the deployment tasks just deploy to a pre-production env which 100% matches, except the deployed instance. If it's all good; I prompt for manual update and off it goes into production.
For further info my VPC looks like this:

The ECS cluster spun up; attaches that that VPC and has default load balancers pre-setup (for cluster global tasks/services) that want to hook into a default one; with resource draining lambas + schedulable containers metrics published.
The service by default though uses isolated resources and just places itself.
I hope that's enough info to get started.


