08:02:38 #startmeeting Introduction to Amazon EC2 Container Service 08:02:38 Meeting started Tue Aug 2 08:02:38 2016 UTC. The chair is jzb. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:02:38 Useful Commands: #action #agreed #halp #info #idea #link #topic. 08:02:38 The meeting name has been set to 'introduction_to_amazon_ec2_container_service' 08:03:58 #info speaker is David Duncan 08:04:02 Agneda 08:04:06 Cluster Management 08:04:10 Benefits 08:04:15 Running Services 08:04:23 Adding the ECS agent to Fedora Atomic 08:04:31 Atomic with ECS in action 08:04:46 why containers? easy for microservices, natural platform for microservices 08:05:08 what happens in public cloud, standard applications and simpler processes are abstracted away to make it simpler for people working with public cloud procuess 08:05:27 building containers is straightforward, what is hard is getting scheduler 08:05:35 businesses come to Amazon and want a way to handle that 08:05:44 figure out what instances you have available, etc. 08:06:08 Start with ec2 instance, is the base for what you're running docker on, inside the docker separate containers, groups of containers, and storage into a task definition. 08:06:23 when you run a task definition, solid group for container management. 08:06:31 track cpu and resources available for containers. 08:06:59 scheduler is responsible for the tasks and their execution, once we have the tasks defined, we use a scheduler, a couple of schedulers to place them where you want. 08:07:20 cluster management engine that underlies the service, no requirement to touch that you you just leverage it for utilization 08:07:44 what we're going to talk about is the ecs agent, running on instances. What you refer to as a standard instance, becomes the container instance. 08:08:09 there is a agent communication service, and api available there. Wraps a lot of docker commands, native access to EC2 container service API. 08:08:45 so, basically what we do to coordinate this, provide a key/value store, the heart of the process that keeps the cluster state available across all the container instances. Maintaining that at scale is a big deal. 08:08:50 Take a look at how we maintain that. 08:08:59 Amazon ECS under the hood: 08:09:16 look at simple transactional algorithm, in key / value store, storing only writes that are handled after the last read, right? 08:09:36 if you're system reads a key value pair, that becomes the snapshot we base next write on. Never get out of order. 08:10:11 if you have multiple clients doing writes/reads, end up where system that's read an n+2 tries to write at n+3, another scheduler that occurs at n+5, only available to write at n+6 step 08:10:31 allows to have a combination of events occurring at different locations, ... goes back to cluster manager to maintain that everything stays the same. 08:10:43 in action, we have the API, agent / communication service all talking to cluster management engine. 08:10:49 all sanity checking done by key/value store. 08:11:07 can actually maintain an entire cluster across a span of high latency communication areas. 08:11:13 clusters are always in a specific region 08:11:36 one of the principles of aws configuration, every region is independent. 08:12:07 multi-region, suggest system that is single region, make latency based across for clients that are hitting systems most local to them. Create restrictions based on geo. 08:12:46 API, choose whatever scheduler you want to use. Can leverage api (all open source on github) to make the requests for resources. Then run those task, run tasks accordingly. 08:12:57 tasks = combination of containers + storage. 08:13:27 multiple schedulers, multiple resources, can schedule task by any one of these, could be long-running, could fit for batch, each one could be working at vastly different rates. 08:13:47 cluster management, always look back to key/value to make sure freed before deployment 08:14:20 if scheduler yellow is trying to access resources ... then there's always going to be [] for that occuring. 08:14:53 we get full scale shared state system, provide your own scheduler for, allocate resources as you see necessary. Container instances ... can then be autoscaled, don't have single group, that are associated with cluster resources. 08:15:06 all of central control and monitoring is happening through cluster management system. 08:15:42 here's some of the scale-out numbers... we do scale up fairly quickly a number of nodes. 08:16:02 Flexible container placement - two specific schedulers by default, one is for long-running, another is for batch jobs. 08:16:33 designed for use with other AWS services, that it touches and easy to integrate, 08:17:07 elastic load balancing, each of your containers present TCP or UDP from container instance, each port can be attached to single load balancer, scale out service, whatever task is ... scale behind single load balancer. 08:18:04 agents are open source 08:18:11 they're extensible 08:18:23 http://github.com/aws/amazon-ecs-agent 08:18:42 http://github.com/aws/amazon-ecs-cli 08:18:58 about open source -easy to pull through ci/cd can roll right into process of creating containers. 08:19:15 can actually provision on process... if you had test vs. product cluster. 08:19:52 look closer at what task definition is. A task is something handled by a container. If you're looking at how that .. is going to run, it's going to be found in task defintion. Also includes storage 08:20:20 you can actually identify how storage is associated with particular container and run command in that definition, altogether will define resources by scheduler in that task 08:20:30 task can be ebs, elastic file system, no s3 08:20:48 can you bring your own storage layer? 08:21:00 Yes - can bring gluster or your own 08:21:04 "Gluster is a great fit" 08:21:09 jzb: Please use #meetingname flock2016 before ending the meeting, it will sort all Fedora Flock talks together in Meetbot. :) 08:21:32 looking at graphic interface, defininig container name, image, max memory, max cpu, port nappings 08:21:36 jflory7: ack 08:21:52 jflory7: what if I used a name when starting? 08:22:03 can also be json file 08:22:22 jzb: #meetingname always overrides for how it's saved in the logs - the name in the meeting is sort of just like an HTML header if you end up using #meetingname later on. 08:22:29 ok 08:22:43 #meetingname flock2016 08:22:43 The meeting name has been set to 'flock2016' 08:22:57 how many units associated with any given tasks and then autoscale accordingly 08:23:16 task defines unit of work, associated with specific containers one or more. 08:23:27 actual resources ... with particular target 08:23:43 create a service - good for long-running applications and services. 08:23:51 create a service, you want to keep running at all times. 08:24:02 associate with a specific load balancer, that will scale out the back end. 08:24:41 anthter thing is , have container instance you've defined 08:24:55 in context of atomic, going in with ostree and literally moving to a different version of the environment. 08:25:26 we can take a machine image for new environment and add that to our stack. Now we actually have a standard red light/green light, multiple auto-scaling groups. 08:25:42 can drain connections out of old systems, and once they're completely drained, go to full new deployment. 08:26:07 now, all of this is the new infra. All scaled down, none of the connections were dropped, we just removed dns entries associated with older instances. 08:26:13 once there's no service load, they can just go away. 08:26:30 Now we're just going to look @ code 08:26:37 grabbing most recent atomic instance 08:26:52 grabbing -1 is the easiest way if you sort by creation date. 08:27:04 once we have that machine image, runinstance command. 08:27:09 whatever size is appropriate 08:27:38 generally choose a small, because a sustained bandwidth - something measurable, rather than something subject to ? 08:28:53 can schedule so all instances are turned off at specific time per day. 08:29:44 grab ecs agent from docker registry, easy to do. Once I have that, now I can create ECS optimized AMI 08:29:58 used a couple of directions with CLI 08:30:05 there's a create-image call don't think I recorded on slide. 08:30:40 current version of atomic, ecs image... is going to maintain that. A couple of commands, associated on github repo, couple of directories to be created for logging. 08:30:56 Once you have those created you want to create the image. 08:31:05 then run create image, for particular instance. 08:31:36 changed behavior to stop from terminate in case anything went wrong still have image to troubleshoot 08:32:05 have generated small cli skeleton, structure for ... parameters, can place that in template, that template can be used to run command consistently. 08:32:26 once you have skeleton, can manage with boto 08:32:34 can manage it programmatically 08:33:15 taking that instance we updated, image ID ... associated with the volume and the instance definition. 08:33:30 if you allocate more storage, those devices will be recreated. 08:34:24 creating instance, could have done through autoscaling, but chose to do as single instance because it's more clear 08:34:39 one instance with default config, for this particular region. 08:34:50 shell in, start container, docker run on configuration. 08:35:02 this is the important part, there's a connnection to unix socket 08:35:06 requires to run privileged 08:35:13 "not a solution, it's a workaround. 08:35:22 --privileged --net=host required 08:35:30 or agent will fail + fail repeatedly 08:36:08 ECS_CLUSTER defines with a specific cluster 08:36:16 if you don't set that, it will set with Default Cluster 08:37:01 specific container instance, assign specific instances, define metrics to scale. 08:47:32 #endmeeting