You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This kind of configuration is not necessarily relevant to this codebase, and the running copy on the server is different from what we have here. I would argue that the server-side copy of deployment configuration should be a read-only copy of what we have on GitHub, and that we should run configurations through CI just like codebases.
This will require a bit of patching and adjustment. My end goal is to have the following kind of architecture server-side:
This means that we will need to be able to refer to services from other running docker-compose configurations by name in the infrastructure configuration. However, it means that we get to use docker-compose-internal networking to isolate each "pod" of containers. For instance, sentry would only be exposed to the outside world through its smtp and web containers; everything else can talk internally on an internal-only network. Similarly, the ccc-server instances could each talk to each other or something over an internal network, but could then also talk to the outside world through the default network.
Obviously, this will all change when have a chance to use Kubernetes. The goal of this issue is to make it so our only work will be changing from docker-compose for orchestration to kubernetes. (And the consequent deployment strategy changes.)
I'll think about this some more before taking steps. Thoughts?
The text was updated successfully, but these errors were encountered:
This kind of configuration is not necessarily relevant to this codebase, and the running copy on the server is different from what we have here. I would argue that the server-side copy of deployment configuration should be a read-only copy of what we have on GitHub, and that we should run configurations through CI just like codebases.
This will require a bit of patching and adjustment. My end goal is to have the following kind of architecture server-side:
This means that we will need to be able to refer to services from other running docker-compose configurations by name in the infrastructure configuration. However, it means that we get to use
docker-compose
-internal networking to isolate each "pod" of containers. For instance,sentry
would only be exposed to the outside world through itssmtp
andweb
containers; everything else can talk internally on an internal-only network. Similarly, theccc-server
instances could each talk to each other or something over an internal network, but could then also talk to the outside world through thedefault
network.Obviously, this will all change when have a chance to use Kubernetes. The goal of this issue is to make it so our only work will be changing from docker-compose for orchestration to kubernetes. (And the consequent deployment strategy changes.)
I'll think about this some more before taking steps. Thoughts?
The text was updated successfully, but these errors were encountered: