Orchestrated, Consistent, and Deterministic Deployment: What Does it Mean and How to Get There (presented by Robert Douglass, VP Customer Success, Platform.sh at eZ Conference 2016)
One of the largest risks and highest costs in any project is the act of deployment. By following Orchestrated, Consistent, and Deterministic Deployment (O.C.D.) principles, you can achieve new levels of efficiency and security that positively impacts your entire organization. This session shares the framework, best practices, and tools (free and commercial) to judge any deployment process as well as investigate current weaknesses, gaps, and shortcomings.
TrustArc Webinar - Unlock the Power of AI-Driven Data Discovery
Orchestrated, Consistent, and Deterministic Deployment: What Does it Mean and How to Get There (presented by Robert Douglass, VP Customer Success, Platform.sh at eZ Conference 2016)
1. OCD Deployment
Obsessive about successful
web-applications
With examples from
Robert Douglass
VP Customer Success, Platform.sh
October 5, 2016
10. “Dealing with Solr indexes on
development and live environments”
“best practices to deal with Search on different
environments, dev, stage prod? i.e. - Not indexing /
corrupting live Solr indexes when testing on dev and
staging.”
15. Orchestrated
For HA Applications, you must provide and configure the following services:
• HA Proxy / Load balancing
• Nginx
• PHP-FPM
• MariaDB (PostgreSQL)
• Solr (ElasticSearch)
• Redis
16. Orchestrated
• Guarantee high availability for all services
• Guarantee disaster recovery for all services
• Guarantee change management for all services
• For every developer and tester, as well as
production.
17. Orchestrated
• Persistent storage:
• Unique needs for mount points, eg. applications
need public, private, and temporary directories
that the web server can write to
• Don't allow storage to be a single point of failure!
Are you using a high-availability, distributed file
system? (eg. GlusterFS, CEPH)
18. Orchestrated
Security Security Security!
• Read-only code deployments
• ACLS
• Physical and network access
• Change management (that guy you just fired)
• Patch levels and vulnerability reactivity:
You actually have to read debian-security-
announce@lists.debian.org
27. Consistent
An OCD Deployment will guarantee that you always:
• Use the same tools to deploy, on every environment
• Know from deploying to (@local / @dev / @test /
@stage / @UAT ) that deploying to @production will
work.
• Consistent infrastructure, Actual data
28. Consistent
Know from one deployment that deployment to @prod
will work:
• Deployment to @local, @stage, @prod etc *all* use
the same tools.
• Weak link: @local
29. Consistent
Work on actual data
• 99% of the time, the data needs to come from @prod
• Data = SQL, uploaded files, Solr index, any other
permanent data store
• When does synchronisation become problematic? 10G?
100G? 1T?
• Sanitise sensitive data outside of @prod
31. “for every event there exist
conditions that could cause no
other event”
Deterministic
32. Deterministic
The goal:
For a given Git repository (hash), exactly the same
application code and infrastructure should be
deployed, every time it is pushed to any environment.
33. Deterministic
Code is assembled with build and make files using technologies like:
• Composer
• NPM
• PIP
• Ruby Gems
• Maven or Ant
35. Deterministic
Deterministic Infrastructure:
• Obvious: use the same services in the same
configuration on every environment you deploy to
(local, dev, staging, testing, UAT, production)
• Less obvious: changing the infrastructure needs to
be a repeatable, reversible action
36. Deterministic
Actual Data:
Data is easily partitioned and fragmented. Examples:
• Files that are in the DB but not on the filesystem.
• Documents not indexed into Solr
• Databases so large they take hours to import/export/
transfer over the wire