Categories

In AWS CloudFormation there is no way to generate the SMTP password of an AWS access key. As a result, the application always has to do the calculation and transform the secret key into an SMTP password. With this custom CloudFormation provider, we put an end to that. read on binx.io

With AWS CloudFormation it is easy to deploy your applications with AWS Elastic Container Service. However, if you want to provide access to your applications through the Kong API Gateway, you are left with one additional step in the deployment process: configuring the Kong gateway. With the Custom CloudFormation Resources for the Kong API Gateway we can deploy both the application and the Kong API Gateway configuration in one go!

In AWS CloudFormation there is no way to generate a private key pair. As a result, you always have manual work. You need to generate a ssh key, import it into AWS and finally pass the name to your CloudFormation template. This is clumsy, manual work which prevents us to fully automate the deployment of our infrastructure.

In this blog we will show you how the provisioning of ssh keys and ec2 key pairs can be automated using Custom CloudFormation Resources.

When you develop an AWS Lambda function in Python, you may require packages which include binary libraries. In this blog we will show you how to use the official Docker Python image to make sure you have a working Lambda.

In a Continuous Delivery pipeline, we like to ensure that every docker image refers to a specific git commit. With this reusable Makefile we ensure that each tag will have a semantic version and point to the exact commit in git at the same time!

One of the biggest pains we encounter in creating immutable infrastructures with CloudFormation, is dealing with secrets. Secrets must be passed into the CloudFormation templates to make them different per environment. Furthermore, these secrets have to passed to development teams, so that they can do something useful with them. Before you know it, your secrets are compromised.

With this Custom CloudFormation Resource we put an end to that. Read more

Amazon AWS makes it really easy for anybody to create and update firewall rules that provide access to the virtual machines inside AWS. Within seconds you can add your own IP address so you can work from home or the office. However, it is also very easy to forget to remove them once your are finished. The utility aws-sg-revoker , will help you maintain your firewall rules.

aws-sg-revoker inspects all your inbound access permission and compares them with the public IP addresses of the machines in your AWS account. For grants to IP addresses not found in your account, it will generate a aws CLI revoke command. But do not be afraid: it only generates, it does not execute it directly. You may want to investigate before removal. Follow the following 4 steps to safeguard your account!

step 1. Investigate

First run the following command to generate a list of all the IP address ranges that are referenced but not in your account.

1

2

3

4

5

6

7

aws-sg-revoker-l

1.2.3.4x.y.z.

4.5.6.7.hostname.com.

5.5.123.4a.b.c.

8.9.10.11/16

....

You may find that you have to install jq and the aws CLI 🙂

step 2. Exclude known addresses

Exclude the ip addresses that are ok. These addresses are added as regular expressions.

One of the reasons Docker caught fire was that it was soo easy to use. You could build and start a docker container in a matter of seconds. With Amazon ECS this is not so. You have to learn a whole new lingo (Clusters, Task definitions, Services and Tasks), spin up an ECS cluster, write a nasty looking JSON file or wrestle with a not-so-user-friendly UI before you have your container running in ECS.

In the blog we will show you that Amazon ECS can be as fast, by presenting you a small utility named ecs-docker-run which will allow you to start a Docker container almost as fast as with Docker stand-alone by interpreting the Docker run command line options. Together with a ready-to-run CloudFormation template, you can be up and running with Amazon ECS within minutes!

Once you start to do some serious work with Docker, you soon find that downloading images from the registry is a real bottleneck in starting applications. In this blog post we show you how you can reduce the size of any docker image to just a few percent of the original. So is your image too fat, try stripping your Docker image! The strip-docker-image utility demonstrated in this blog makes your containers faster and safer at the same time!

Most examples on the deployment of Docker applications to CoreOS use a single docker application. But as soon as you have an application that consists of more than 1 unit, the number of commands you have to type soon becomes annoying. At Xebia we have a best practice that says “Three strikes and you automate” mandating that a third time you do something similar, you automate. In this blog I share the manual page of the utility called fleetappctl that allows you to perform rolling upgrades and deploy Consul Key value pairs of composite applications to CoreOS and show three examples of its usage.

fleetappctl is a utility that allows you to manage a set of CoreOS fleet unit files as a single application. You can start, stop and deploy the application. fleetappctl is idempotent and does rolling upgrades on template files with multiple instances running. It can substitute placeholders upon deployment time and it is able to deploy Consul key value pairs as part of your application. Using fleetappctl you have everything you need to create a self contained deployment unit of your composite application and put it under version control.

The command line options to fleetappctl are shown below:

Shell

1

2

3

fleetappctl[-ddeployment-descriptor-file]

[-eplaceholder-value-file]

(generate|list|start|stop|destroy)

option -d

The deployment descriptor file describes all the fleet unit files and Consul key-value pair files that make up the application. All the files referenced in the deployment-descriptor may have placeholders for deployment time values. These placeholders are enclosed in double curly brackets {{ }}.

option -e

The file contains the values for the placeholders to be used on deployment of the application. The file has a simple format:

Shell

1

<name>=<value>

start

starts all units in the order as they appear in the deployment descriptor. If you have a template unit file, you can specify the number of instances you want to start. Start is idempotent, so you may call start multiple times. Start will bring the deployment inline with your descriptor.

If the unit file has changed with respect to the deployed unit file, the corresponding instances will be stopped and restarted with the new unit file. If you have a template file, the instances of the template file will be upgraded one by one.

Any consul key value pairs as defined by the consul.KeyValuePairs entries are created in Consul. Existing values are not overwritten.

generate

generates a deployment descriptor (deployit-manifest.xml) based upon all the unit files found in your directory. If a file is a fleet unit template file the number of instances to start is set to 2, to support rolling upgrades.

stop

stops all units in reverse order of their appearance in the deployment descriptor.

destroy

destroys all units in reverse order of their appearance in the deployment descriptor.

list

lists the runtime status of the units that appear in the deployment descriptor.

Example – Three component web application

The first example is a three component application. It consists of a mount, a Redis database service and a web application. We generate the deployment descriptor, indicate we do not want to start the mount, start the application and then modify the web application unit file to change the service name into ‘helloworld’. We perform a rolling upgrade by issuing start again.. Finally we list, stop and destroy the application.

Example – placeholder references

This example shows the use of a placeholder reference in the unit file of the paas-monitor application. The application takes two optional environment variables: RELEASE and MESSAGE that allow you to configure the resulting responses. The variable RELEASE is configured in the Docker run command in the fleet unit file through a placeholder. The actual value for the current deployment is taken from an placeholder value file.

Shell

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

cd../fleetappctl-0.25/examples/paas-monitor

#check out the placeholder reference

grep'{{'paas-monitor@.service

...

ExecStart=/bin/sh-c"/usr/bin/docker run--rm--name%p-%i\

<strong>--envRELEASE={{release}}</strong>\

...

# checkout our placeholder values

catdev.env

...

release=V2

# start the app

fleetappctl-edev.envstart

# show current release in status

curl paas-monitor.127.0.0.1.xip.io:8080/status

# start is idempotent (ie. nothing happens)

fleetappctl-edev.envstart

# update the placeholder value and see a rolling upgrade in the works

echo'release=V3'>dev.env

fleetappctl-edev.envstart

curl paas-monitor.127.0.0.1.xip.io:8080/status

fleetappctl destroy

Example – Env Consul Key Value Pair deployments

The final example shows the use of a Consul Key Value Pair, the use of placeholders and envconsul to dynamically update the environment variables of a running instance. The environment variables RELEASE and MESSAGE are taken from the keys under /paas-monitor in Consul. In turn the initial value of these keys are loaded on first load and set using values from the placeholder file.

Shell

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

cd../fleetappctl-0.25/examples/envconsul

#check out the Consul Key Value pairs, and notice the reference to placeholder values

catkeys.consul

...

paas-monitor/release={{release}}

paas-monitor/message={{message}}

# checkout our placeholder values

catdev.env

...

release=V4

message=Hi guys

# start the app

fleetappctl-edev.envstart

# show current release and message in status

curl paas-monitor.127.0.0.1.xip.io:8080/status

# Change the message in Consul

fleetctl ssh paas-monitor@1\

curl-XPUT\

-d\'hello Consul\'\

http://172.17.8.101:8500/v1/kv/paas-monitor/message

# checkout the changed message

curl paas-monitor.127.0.0.1.xip.io:8080/status

# start does not change the values..

fleetappctl-edev.envstart

Conclusion

CoreOS provides all the basic functionality for a Container Platform as a Service. With the utility fleetappctl it becomes easy to start, stop and upgrade composite applications. The script is an superfluous to fleetctl and does not break other ways of deploying your applications to CoreOS.