Embed Size (px)
Citation preview
Agenda
• Introduction
• Continuous Delivery and Docker 1. The past
2. The present
3. The future
• Q&A
Introduction
• Bob Marks
• 14 years industry experience
• Worked mostly in software start-up scene
• Currently at Adoreboard (Head of Engineering) • Adoreboard is a spin-out company from Queen’s University Belfast
• Adoreboard measures how the world feels about your brand, your marketing campaigns and your competitors.
• Key value proposition is emotional analysis
• This presentation explores how both “Continuous Delivery” and “Docker” has helped Adoreboard in 2015
1. “The Past”
Engineering process @ SOY 2015
• 2 GIT repos hosted on bitbucket 1. adoreboard-api
• Java - 5 WARs
• several text analysis JARs
2. adoreboard-ui • NodeJS / JavaScript project
• Jenkins as build tool
• Artifactory as repository manager
• Everything hosted on Microsoft Azure cloud
Development / releases @ SOY 2015 • GitFlow – “A successful Git Branching
Model”
• 2 main / 3 “short-lived” branches
• 6 main Jenkins jobs
• Pros: – • Clear separation between features and
bug fixing
• Cons: – • We 1 release per sprint (~ 12 max per
year) • More complexity i.e. parallel branches • Loads of time spent on merge conflicts
Testing @ SOY 2015
• Adoreboard • No dedicated testers – testing done by developers • Decent unit / integration testing in API / UI projects • No acceptance testing
• We had a stab at UI acceptance tests • Were unreliable as dependant on state in API / databases
“The Past” - closing thoughts • Releases were complex and time consuming / 1 per sprint
• No ability to release to customer at “any time”
• No reliable acceptance testing
• IMO GitFlow may be useful for e.g. library software. Less suited for SaaS / cloud apps
2. “The Present”
What is “Continuous Delivery”? • Software development discipline
• Martin Fowler states it as: - • “The current development version of the software can be
deployed into production at a moment's notice”
• Also states: - 1. software deployable throughout its lifecycle 2. priority of keeping software deployable over new features 3. fast, automated feedback on the production readiness
after each code submit 4. push-button deployments of any version of the software to
any environment
• Builds on “continuous integration” – mostly dealing with final stages of build
• Generally achieved via “build pipelines”
• Benefits: - 1. Reduced Deployment Risk (deploying smaller changes) 2. Believable Progress (deployed to customer) 3. User feedback
Implementing CD
• Jenkins + several new Plugins
• Workflow similar to GitHubFlow
• Mainline model - master branch • feature-X branches for features • pull requests on features –
merged to master • Minor fixes / bugs straight into
master
• “Everything in GIT” e.g. • Configuration • Infrastructure as code
“The mainline model is strongly recommended in CI and CD paradigms” -
WANDisco Blog Article
Jenkins Build Pipelines View
• 5 “pipelines”
• Most build pipelines arranged in 4 stages
• 52 total jenkins jobs!
• Each task is Jenkins job
• Visually more informative
• “Fail fast”
Jenkins “All Jobs” view
• mvn test • mvn install -DskipITs
• mvn deploy
• SSH Staging
staging.
adoreboard.
com
• curl /api/pulse
What is a Smoke Test? • Quick test to check system is live
• Continuous Delivery - page 123 “Why unit tests Aren’t Enough”
• 90% unit test coverage
• Someone noticed deployed system wasn’t working and stepped back through versions
• Tiny bug prevented system from starting
• System had not been working for 3 weeks!!!
• GIT – adoreboard-api
• mvn clean compile
• docker push …
• docker build …
test.
adoreboard.
com
• SSH to QA server
• docker compose up
• gulp acceptance-test --url='http://test.adoreboard.com'
• mvn clean test -Dhost=test.adoreboard.com
• AWS Upload
• curl /api/pulse
• curl /data/pulse
• curl /processor/pulse
• curl /calculator/pulse
• mvn \ build-helper:parse-version \ versions:set -DnewVersion=\ ${parsedVersion.majorVersion}.\ ${parsedVersion.minorVersion}.\ ${parsedVersion.nextIncrementalVersion}\ versions:commit
• “Docker allows you to package an application with all of its dependencies into a standardized unit for software development” - Docker website
• VM images are big (e.g. 2GB) as they contain an OS
• Docker images are massively smaller, especially if based on stripped down OS like BusyBox (e.g. 20 MB)
• Docker files can be checked into GIT – CD friendly
• Docker Hub is community repo of 100,000+ registries
• We created the following docker files: - 1. RabbitMQ ubuntu 2. MongoDB ubuntu 3. Elasticsearch ubuntu 4. AdoreboardAPI tomcat + 5 WARs 5. AdoreboardUI node + UI app
• We used MySQL directly from Docker Hub.
FROM tomcat:7-jre7
MAINTAINER adoreboard
ADD admin.war /usr/local/tomcat/webapps/
ADD api.war /usr/local/tomcat/webapps/
ADD data.war /usr/local/tomcat/webapps/
ADD processor.war /usr/local/tomcat/webapps/
ADD calculator.war /usr/local/tomcat/webapps/
EXPOSE 8080
ENTRYPOINT ["catalina.sh","run"]
Example Docker File – Tomcat + API WARs
• Building / deploying docker file docker build -t repository.adoreboard.com/adoreboard/tomcat
/jenkins/workspace/adoreboard-docker/tomcat
docker push repository.adoreboard.com/adoreboard/tomcat
• Tool for defining and running multi-container Docker applications.
• You use a Compose file (docker-compose.yml) to configure your application’s services.
• Then, using a single command, you create and start all the services from your configuration
• sudo docker-compose up –d
• Use curl to check WARs / UI is up
• After acceptance test • sudo docker-compose down
What is Docker Compose?
API UI
rabbitmq:
image:
repository.adoreboard.com/adoreboard/rabbit
ports:
- "5672:5672"
- "15672:15672"
mongo:
image:
repository.adoreboard.com/adoreboard/mongo
ports:
- "27017:27017"
elasticsearch:
image:
repository.adoreboard.com/adoreboard/elasticsearch
ports:
- "9200:9200"
mysql:
image: mysql
ports:
- "3306:3306"
environment:
MYSQL_DATABASE: adoreboard
MYSQL_ROOT_PASSWORD: <some_pwd>
MYSQL_USER: adoreboarduser
tomcat:
image:
repository.adoreboard.com/adoreboard
/tomcat
environment:
SPRING_PROFILES_ACTIVE: "docker"
DOMAIN_URL: http://localhost:8080
JAVA_OPTS: " -Xms4g -Xmx4g"
ports:
- "8080:8080“
links:
- mongo
- elasticsearch
- mysql
- rabbitmq
adoreboardui:
image:
repository.adoreboard.com/adoreboard
/adoreboard-ui
ports:
- "3000:3000“
links:
- tomcat
environment:
- DEBUG=adoreboard
Docker Compose – Configuration Caveat
• Tomcat configuration on staging server looks like: - jdbc.url=jdbc:mysql://localhost:3306/adoreboard
mongodb.host=localhost
elasticsearch.url=http://localhost:9200
rabbitmq.addresses=localhost:5672
• Doesn’t work in Docker Compose because • each container has it’s own IP address e.g.
172.17.2.186 mongodb 172.17.2.187 mysql … etc
• However, docker compose creates environment variables for linked containers.
API
Docker Compose – Configuration Caveat (2) • If you SSH onto e.g. the Tomcat container and type set you’ll see special environment
varables …
MONGO_NAME=/adoreboarddocker_tomcat_1/mongo
MONGO_PORT=tcp://172.17.1.204:27017
MONGO_PORT_27017_TCP=tcp://172.17.1.204:27017
MONGO_PORT_27017_TCP_ADDR=172.17.1.204
MONGO_PORT_27017_TCP_PORT=27017
MONGO_PORT_27017_TCP_PROTO=tcp ...
• Don’t know in advance what these IP addresses are so but we can use these environment variables e.g. env-docker.properties (overrides main property file when Spring profile set to “docker”)
jdbc.url=jdbc:mysql://${MYSQL_PORT_3306_TCP_ADDR:localhost}:3306/adoreboard
mongodb.host=${MONGO_PORT_27017_TCP_ADDR:localhost}
elasticsearch.url=http://${ELASTICSEARCH_PORT_9200_TCP_ADDR:localhost}:9200/adoreboard
rabbitmq.addresses=${RABBITMQ_PORT_5672_TCP_ADDR:localhost}:5672
3. “The Future”
Further CD / Docker Improvements
• Use different CD software e.g. GO
• More advanced rollbacks
• Greater use of Docker i.e. staging / production
• Green / Blue Deployments
• Data-Driven Decision Making e.g. 2 deployments, measure metrics on feature
• Further tasks / stages to pipeline • e.g. performance / capacity testing
Conclusion
• Continuous Delivery • Faster releases (sometimes several / day) • Minimal drama on releases • Higher speed-to-market on features / bugs • Greater visibility on weak points in pipeline • Reduced cost (big releases => high cost)
• Docker • Enabled QA Stage in CD Pipeline / robust acceptance tests • Lightweight footprint / minimal overhead • Portable across machines • Version controlled so easily tweaked
• Final thought - Automate everything! • (deployments, testing, scripting, cloud)!
