It has aways been a problem for Dokku users to easily build multi-server architectures. This because Dokku of course only runs and manages one server. Thus, making a multi-server architecture is quite hard to maintain.
To make multi-server apps with Dokku work, there are two components:
something would have to manage the configuration and deployments across servers so that all running applications have the same domain and environment variable settings
something would have to manage new code deployments to the server. Eg: a single git push URL or some other thing that pushes code to multiple servers.
Why would we want to make Dokku multi-server? Especially in the scope that Dokku is often used: single developers or small companies.
The main reason for us would be high availability in the scope of security updates. Whenever an individual server needs to get an OS update or a kernel upgrade, you cannot apply these without causing downtime. Thus having at least 2 Dokku servers behind a load balancer would solve this. You can then bring down one Dokku server, do updating and rebooting, and then bring it up again.
The proposal in this issue focuses mainly about a pragmagic way to solve issue one, across multiple servers. Thus, allowing Intercity to provide Dokku users with the means to define a single application configuration, and have that managed across Dokku-enabled servers.
As a use case in practice, I have the following in mind:
The databases (Postgres, Redis, MySQL, etc.) of the application are run externally. For example on aiven.io, or through AWS RDS.
A load balancer or reverse-proxy is placed in front of the application servers to manage domain mapping and for example SSL termination.
Intercity will be able to provision and manage two servers in such a setup. This way we have one fallback, to be able to upgrade the other.
There are a few strategies how we could already solve this. The following lists some high level directions. I'm sure there are more or variants:
You create a server group in Intercity. Intercity provisions servers added to the server group with standard Dokku installations. You define configurations for applications on the group. Changes to applications in the group are instantly applied to all servers.
You can add an application on a server, but tell it to use settings from an application already configured with Intercity. Whenever the original application's configuration is updated, it will also update configurations on all dependent servers.
The deployment thing won't be solved yet by these approaches. But it's ok to simply list some nodes in a CI or Capistrano file that will be updated on a deploy. We're talking about the use case of 2-5 servers here.
It has aways been a problem for Dokku users to easily build multi-server architectures. This because Dokku of course only runs and manages one server. Thus, making a multi-server architecture is quite hard to maintain.
To make multi-server apps with Dokku work, there are two components:
Why would we want to make Dokku multi-server? Especially in the scope that Dokku is often used: single developers or small companies.
The main reason for us would be high availability in the scope of security updates. Whenever an individual server needs to get an OS update or a kernel upgrade, you cannot apply these without causing downtime. Thus having at least 2 Dokku servers behind a load balancer would solve this. You can then bring down one Dokku server, do updating and rebooting, and then bring it up again.
The proposal in this issue focuses mainly about a pragmagic way to solve issue one, across multiple servers. Thus, allowing Intercity to provide Dokku users with the means to define a single application configuration, and have that managed across Dokku-enabled servers.
As a use case in practice, I have the following in mind:
There are a few strategies how we could already solve this. The following lists some high level directions. I'm sure there are more or variants:
The deployment thing won't be solved yet by these approaches. But it's ok to simply list some nodes in a CI or Capistrano file that will be updated on a deploy. We're talking about the use case of 2-5 servers here.