There is no lack of deployment software in the OpenStack market, and each one of them provides great value from different perspective and scenario. These deployment solutions did a great job on software deployment layer based upon OS provisioning tools like Cobbler and configuration management tools like Puppet/Chef, but they generally do not go deep down to networking and server hardware level configuration, which is a key step for large scale OpenStack solution. As part of a networking company and a server vendor, Huawei Cloud team are developing Compass, a system not only for OpenStack software deployment, but also for fully automated hardware level server and networking gear configuration. Our system automates hardware resource discovery, hardware configuration (e.g., hardware RAID configuration, switch configuration), topology-aware OpenStack service deployment and etc. Therefore, end users have a streamlined OpenStack deployment experience with Compass. We are using Compass for deploying OpenStack cloud in our Telco customer sites and got very constructive feedback for us to make more robust and open deployment solution. We plan to open source our project. One major goal we have in designing the system is to achieve true openness at hardware level, so that other hardware vendors can write plug-in toward their special server designs. Just like OpenStack openness makes it a valuable game-changing cloud solution, we hope we can work with other hardware vendors to make OpenStack universally available on various hardware platforms in a streamlined fashion.
When you type “cap deploy”, “ey deploy”, or “git push heroku master” your intent is to deploy your local application source to your running system on the Internet. That seems to be the point - you changed your code, and you want to Just Ship It. But what is your actual objective? Is it really to just “deploy app code changes”? Is this “app-centric” view and user experience satisfactory?
Code deployment is your intent on some occasions. On others you want to change your production environments for applications, or change scale attributes of your system, or change how applications and services within a system communicate with each other, or with remote services (such as facebook).
Is “app-centric deployment” the best mental model and toolchain for shipping changes to productions systems? Or is “environment-centric” or “node-centric”, enabled with frameworks like Chef or Puppet, the most powerful & effective model of the system to allow you to deploy and manage change?
Or perhaps we should describe the entire system - all the apps, all the system dependencies, all the interconnections, all the scale attributes - and command it to come into existence? To command the system to go from nothing to v1 to v2 to v3, where each version includes changes in attributes of the system.
Where should configuration/manifests/attributes go? Source code files in the config folder? PaaS configuration or environment variables? Or should components of a system dynamically discover information about itself and configure itself?
Perhaps we need the benefits of a “system-centric” build toolchain, with an “app-centric” user/developer experience to trigger deploys, with a “node-centric” experience for sysadmins.
In this talk, we will reflect on the current state of deploying production systems, including build/deploy toolchains, and continuous deployment. We’ll look at the attributes of a complete system, how we explicitly or implicitly describe them and their relationships, and how to orchestrate changes in the system - from app-centric, node-centric and system-centric views.
Let’s discuss the difference between deployment in month 1 and living with your system for the next 59 months.
What does it take to deploy an application without any downtime?
More than most Ruby developers would expect, turns out; what is aggravated by the lack of documentation and other resources on this topic.
In this talk we'll dive into both development practices (hot compatibility, database migrations, caching) and deployment setup (Heroku, Unicorn, HAProxy), covering everything you need to know in order to ship code without affecting a single customer.
Typical cloud deployments – be it OpenStack, CloudStack, Eucalyptus etc – have a separate control layer installed and upgraded using separate tools (which might be hand-configured PXE + preseeding, Cobbler, Orchestra/MAAS) As a result you have two distinct provisioning systems in play, which allows for more user error and increased special cases in automation. Add to this the increasing complexity of the puppet or chef descriptions of such setups, and you can soon go mad and be stymied by fear of change.
Contrast that with the new generation easy things we can do in the cloud. Upgrade? Why bother – just spin up the new version of your app in parallel, then let your HA system fail over to it, then de-provision the old version.
So what if we could get all of the power that we have in the cloud when we’re running our datacenters, without the cost overhead of virtualization?
Starting with a bare-metal driver for OpenStack Compute (nova) and coupling that with OpenStack Orchestration (heat) and a pipeline for building cloud-style non-installer based disk images, we can do just that. Provision and manage your entire data center with the flexibility of a managed virtual cloud and all the power of running on actual metal.
So...Continuous Deployment. You hear that you should be practicing continuous deployment, but nobody every pointed out that there are many different ways to do it!
This talk compares and contrasts different kinds of continuous deployment strategies. Implementation, requirements, tradeoffs will be covered. Case-studies, examining different strategies practiced at companies such as Facebook, GitHub, IMVU, Heroku and CircleCI.
Like most programmers I am lazy. I don't want to do something by hand if I can automate it. I also think DevOps can be dreadfully dull. Luckily there are now tools that support lazy DevOps. I'll demonstrate how using Docker containers and Kubernetes allows you to be lazy and get back to building cool features (or watching cat videos). I'll go over some of the pros and cons to the "lazy" way and I'll show how these tools can be used by both simple and complex apps.