Deploying services: automation with docker and ansible
•Download as PPTX, PDF•
1 like•1,200 views
As micro-service architecture scales, the time spent provisioning new environments and deploying multiple services slows down feature development and increases time to market. In this session we will look at some ways to solve these problems- mainly using hot technologies: Docker and Ansible.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Deploying services: automation with docker and ansible
Similar to Deploying services: automation with docker and ansible (20)
Recently uploaded
Recently uploaded (20)
Deploying services: automation with docker and ansible
- 1. Deploying Services: Automation with Docker and Ansible John Zaccone - Software Engineer http://www.ipponusa.com
- 2. About Me ● Worked at Ippon for 1 year ● First project: Allianz Travel Insurance ● Joined the project during some big architecture decisions 2
- 4. Architectural Decisions: Requirements ● Increase sales ○ modern UI and responsive design ● Move towards Java 8 / Spring services ● Active-Active ● Standardize on CMS Platform 4
- 6. After 6
- 7. Architecture Benefits ● Flexible technology choices ● APIs, APIs, APIs ● Change/Deploy Independently ● Stateless for Scalability 7
- 8. What Microservices Means to Us Team Members: 4-5 Services: 4 Environments: 4 Running Application: 16+ *Each new service adds at least 4 more running containers. 8
- 9. Things that take up my time ● Deploying services ● Installing services on new environments ● Dealing with problems with differences between environments ● Waiting for new VMs 9
- 10. I Need More Time for Coffee Breaks Automation- repeatable for all environments Containerize - environmental dependencies Isolation- run multiple apps on 1 VM Spin up new environments quickly. 10
- 12. Docker and Ansible Ansible Non-environment specific automation Declarative Easy for devs 12 Docker Fast spin up Isolated applications Immutable infrastructure “Works on my machine” Docker Toolbox
- 13. Architecture With Docker Containers 13
- 14. Making the Most of Your Servers 14
- 15. Decoupling Automation from Environments 15
- 16. Decoupling Automation from Environments 16
- 17. Demo Time 17
- 18. Advanced Tips ● Build and push images with CI tools ● Link containers on the same host with --link ● Use a restart policy on your containers ● Stay on the latest docker version ● Use ELK for centralized logging ○ Alternative: “EFK” (Fluentd in lieu of Logstash)18
- 19. We Do Training! ● Training Sessions ● Brown Bags ● romain@ipponusa.com 19
Editor's Notes
- Worked at Ippon as a Software Engineer for 1 year First project: Allianz Travel Insurance Personal Experiences Big architecture decisions
- Old site www.allianztravelinsurance.com Mostly .NET shop, website consisted of a suite of .NET services
- Ippon joined the project meet some goals: increase sales modern UI response design IT goals move towards Java 8 spring services Support active-active infrastructure high availability automate failover with zero downtime Global goals standardize on a common CMS Platform JBOSS Portal
- Resulting architecture: Services (or microservices) architecture CMS Platform to serve static html content Services called from javascript: Content API spring boot/ java 8 populate dynamic content for templates article landing page with list of article snippets Policy API spring boot/ java 8 purchase policies, manage policies, get a quote Connects with existing .NET services Both New APIs acted as facades on top of the CMS and Legacy .Net services contract-first approach
- Benefits of the architecture we chose flexible technology choices added business value with new spring boot services while making full use of the existing legacy services CMS Platform Benefits of getting everyone on the same platform But it’s big, slow-evolving Existing app functionality outside platform Needed to adopt, but maintain functionality lower dependency risk Use services to achieve this APIs facades for cleaner interfaces now internal policy API provides a possible revenue channel policy path Deploy Independently From each other, and from legacy application Push value to production faster lower time for critical bugs fixes Services our stateless maintain active-active infrastructure scale and failover smoothly
- New architecture = advantages, but problems too time spent Managing deployments of multiple services A little bit about our team 5 team members 4 services 4 environments Running applications = services * environments Each new service = 4 more running applications
- > time managing deployments, < time developing new features
- To solve this problem, and to give myself more time to drink coffee, I mean, develop new features Automation works on any environment Differences in environments containerize my dependencies as apart of my delivered application Level of isolation multiple apps on one host Spin up new environments quickly when introducing a new service
- Docker and Ansible.. Yayyyyyy For those of you are familiar with these technologies, you will know that these are great tool to solve my problems And heres why
- Docker Packages everything you need to run into a container file system, system libraries a standardized abstraction called a container light weight Spinning up new containers is fast not full blown OS Containers are isolated 1 application per container Containers are isolated >1 container on same host Immutable infrastructure Avoid environment drift installing/updating packages (even security) can cause problem difficult to debug, difficult to rollback drift gets worse for long-running applications Docker containers launched from images read-only to upgrade an application completely replace running container developer visibility into environmental dependencies Include environmental dependencies apart of your deliverable Eliminates problems between environments Works natively on linux Toolbox will enable you to use on Windows and Mac Ansible Automation tool Application installation configuration management Not specific to a single environment Reuse automation Declarative what we want to accomplish but not how to achieve it Ansible executes what’s needed while avoiding side effects Guaranteed idempotency inside the core modules don’t need to know state Easy to use for developers > role in operational support True for us
- Same diagram as before, except with green boxes Docker containers for CMS, Content API and Policy API Apache web server in a container Data-only container for our content database In production
- Isolation = multiple applications without problems Benefits are two fold One, in development, available VMs Two, lower infrastructure cost
- Why ansible is so cool Runs automation off a central location Uses ssh on other servers Using Ansible on server 1...
- Using the exact same automation, we can upgrade all the application on server 2
- CI tools to build and push docker images We use jenkins Link Containers on the same host containers are isolated from each other create a connection using --link Restart policies Server reboot Linked containers will start in order Systemd can also be used Give yourself the ability to stay up to date on the latest version of docker evolving rapidly logging bug ELK for centralized logging- Elastic search, log stash and kibana. fluentd Log stash centralizes log post-processing elasticsearch indexes logs kibana to search and define filters, views, dashboards You need alerting and monitoring and a way to quickly debug an issue.