SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez nos Conditions d’utilisation et notre Politique de confidentialité.
SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez notre Politique de confidentialité et nos Conditions d’utilisation pour en savoir plus.
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.
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
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.
Deploying services: automation with docker and ansible
Deploying Services: Automation
with Docker and Ansible
John Zaccone - Software Engineer
● Worked at Ippon for 1 year
● First project: Allianz Travel Insurance
● Joined the project during some big
● 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
We Do Training!
● Training Sessions
● Brown Bags