A few weeks ago, I wrote a blog post on the topic of setting up and deploying your database with Cloud 66. It generated some further discussion around switching server resources between an external database and one hosted on Cloud 66, what to do when upgrading or switching databases, and whether it’s possible to share servers when deploying separate stacks.
To bring some clarity to the matter, this post will focus on providing you with some guidance on server management.
Building Immutable Infrastructure
Cloud 66 aims to make it easier to build immutable infrastructure and we consider building servers and stacks from scratch each time you have a new deployment a best practice. It’s a more salient approach than modifying existing server configurations and/or tinkering with settings to the point where you suddenly start to find things not working. Taking this route is difficult, time consuming and can be unpredictable.
Each time you want to setup a new stack with Cloud 66, you’ll need a fresh server instance. If you already have a running stack on a server, we cannot set up a second stack on the same kit. So if you’re attempting to upgrade to a new database version, our first recommendation is to build a new stack and redirect your traffic to the new stack using our Elastic Address.
With the ease of switching cloud resources on and off as needed makes applying this method more achievable, and that’s why we’ve always put a lot of effort in to making building stacks from scratch as easy and quick as possible. We also offer lots of scope for applying advanced configuration settings through the [use of manifest files](( http://help.cloud66.com/building-your-stack/building-your-manifest-file).
Configuring settings of your Stack
A manifest file allows you to describe the setup of the components that run your stack. By using a manifest file, you can be more explicit about your stack composition and the control settings you want to apply including:
- Defining sizes and data center region for your servers
- Specifying a component version
- Configure your stack components to share a server
- Customize component-specific configurations
Manifest file settings can be applied during the build of a new stack or an existing stack depending on the type of setting. The changes you make to your manifest are mostly applied during provisioning - especially the ones related to infrastructure. So for instance, if you change your ruby version in your manifest file and redeploy, the ruby version won't change but if you add a new web server to your stack, the new one will contain the updated ruby version.
The manifest file is called manifest.yml and is YAML formatted. The first level of the manifest.yml is the environment of your stack. This allows you to use the same manifest.yml for multiple stacks with different environments.
The second level is the application type and determines which parts of the stack are affected by this section. And the third level of the manifest file determines the specific settings for the application type we want to change, as well as providing the ability to have specific settings per server as well.
You can find out more about how to configure your server settings with manifest files here . There's more content like this on our Community site and on our Help pages. And if you haven't already, make sure you join the Cloud 66 Slack community to get involved.