Many companies are moving away from “big bang” software releases every six months or so to a continuous delivery (CD) model that enables IT to release updates frequently, even if that means several times a day. Our experts can show you how to automate deployments with Q.Launch across multiple cloud accounts, regions, and even across multiple cloud platforms into continuous deployment pipelines. You’ll learn how Q.Launch enables your company to design and automate a delivery process that not only fits your release cadence, but also the business criticality of your application.
BUILT-IN DEPLOYMENT BEST PRACTICES
Create and deploy immutable images for faster rollouts, easier rollbacks, and the elimination of hard to debug configuration drift issues. Leverage an immutable infrastructure in the cloud with built-in deployment strategies such as red/black and canary deployments.
You can define Clusters, which are logical groupings of Server Groups in Q.Launch.
Deploy across multiple cloud providers including AWS EC2, Kubernetes, Google Compute Engine, Google Kubernetes Engine, Google App Engine, Microsoft Azure, Openstack, Cloud Foundry, and Oracle Cloud Infrastructure, with DC/OS coming soon.
A Load Balancer is associated with an ingress protocol and port range. It balances traffic among instances in its Server Groups. Optionally, you can enable health checks for a load balancer, with flexibility to define health criteria and specify the health check endpoint.
A Firewall defines network traffic access. It is effectively a set of firewall rules defined by an IP range (CIDR) along with a communication protocol (e.g., TCP) and port range.
Create deployment pipelines that run integration and system tests, spin up and down server groups, and monitor your rollouts. Trigger pipelines via git events, Jenkins, Travis CI, Docker, CRON, or other Q.Launch pipelines.
An application in Q.Launch is a collection of clusters, which in turn are collections of server groups. The application also includes firewalls and load balancers.
An application represents the service which you are going to deploy using Q.Launch, all configuration for that service, and all the infrastructure on which it will run.
You will typically create a different application for each service, though Q.Launch does not enforce that.
The base resource, the Server Group, identifies the deployable artifact (VM image, Docker image, source location) and basic configuration settings such as number of instances, autoscaling policies, metadata, etc. This resource is optionally associated with a Load Balancer and a Firewall. When deployed, a Server Group is a collection of instances of the running software (VM instances, Kubernetes pods).
Copyright © 2020 Qosil, LTD
An Asset of The Freedom Nation
A Subsidy of GeniusCo