Cloud 66 changelog cloud66.com

Today I am very happy to announce the release of Multi Database, our latest feature. Multi Database lets you attach multiple groups of databases to your applications! These groups can be of different types, or the same type, depending on your needs.

We've been working on this feature for a while, and we are pretty excited about it. It allows for a variety of compelling use-cases:

• Running multiple databases in Rails 6
• Running different replicated versions of a database
• Easily switching target database groups for your application
• …and more!

If you're interested in this feature, check out the blog announcement and our Multi Database documentation.

Customers can now transfer the ownership of their applications between different Cloud 66 accounts. The application and its servers are not affected by the transfer process. Please note that the application, source account, and destination account, all need to meet minimum criteria in order to be eligible for the transfer. For more information please see our stack transfer documentation

Good news for anyone who has been frustrated by this in the past! The Toolbelt (cx) redeploy command (help doc) will now behave correctly when running against an already-deploying application (when you are using the --listen argument). This replaces the previous behavior which would simply return “application is busy”. This is especially useful for enqueuing deployments via CI systems.

Today we are rolling out the first phase of our new Application Health Check system. This new system is based on checking the health of your application's HTTP endpoints from different locations around the world. From today, when you raise a support ticket on the site, we check your application's HTTP endpoint from 5 different locations (US East, US West, Netherlands, Australia and Japan) and include that information on the ticket.

We have bigger plans for Application Health Checks and can't wait to share them with you soon.

We are pleased to announce the Beta release of component tag propagation to cloud providers. This allows you to more easily identify and link components across different platforms. At the moment the components that support this feature are cloud servers and load balancers. For a list of the cloud providers that support this feature, and additional information, please see our Tagging components help documentation.

Tag propagation is available to our Beta Program members. If you would like to join our Beta Program, head to your Account page and check the box for Beta Program.

For our Rails/Rack users, in case you missed it earlier this week, Ruby v2.7.2 is now available. For more information, see the official release notes.

We have just released support for user-defined Kubernetes labels and annotions on Maestro stacks. We use the tags key on your service.yml to determine your Kubernetes Resource labels, and the new annotations key on your service.yml to determine your Kubernetes Resource annotations. For examples and more detail please see the Service Tags and Annotations help documentation

All Cloud 66 customers can now track progress of their support tickets, as well as see a list of their previous support tickets under the Support link on the dashboard. As your ticket moves around within Cloud 66 (1st Line support, 2nd line escalation, etc) it will be updated on this page so you can keep track of its progress.

To see this page, click on the Support link on top of your dashboard.

Today I am excited to announce general availability of Service Accounts. Service Accounts are like team members that cannot login to the UI. They can be used to setup automation or notifications that are not bound to a real person.

If you use notifications like Slack for your Cloud 66 applications, you probably want to limit them to a single notificaiotn per event. More importantly, you would like your notifications and API integrations not to be linked to a real person, so they won't break when they leave your team. Service Accounts are perfect for that: Setup a Service Account and use them to enable notifications, CX (Toolbelt) or API integrations as you would with a real team member.

You can find more information about Service Accounts on our blog

There are some scenarios in which your Kubernetes cluster could become unavailable. The most common cause of this issue is a cluster with a single master that runs out of memory or gets locked into scheduling services that are utilizing all of its available resources. This can cause processes to be killed, the cluster to become unreachable, and, in the worst cases, corrupt the master. The fastest way to resolve this is to repair your cluster, essentially reinitializing it as new.

Now, if you're faced with this scenario, you can run the repair operation yourself! We've replaced our deploy-with-options overlay with a side-drawer component which gives us some more space to work with. Take a look at our help documentation for more on this new option!