Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove NGINX configuration from this repository #57

Open
rye opened this issue Aug 11, 2018 · 0 comments
Open

Remove NGINX configuration from this repository #57

rye opened this issue Aug 11, 2018 · 0 comments
Assignees

Comments

@rye
Copy link
Member

rye commented Aug 11, 2018

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:

                  * <other tools>
                 /
                | * sentry
                |/
[internet] ---> * nginx (configuration from @frog-pond/infrastructure)
                |\
                | * ccc-server (st olaf instance)
                 \
                  * ccc-server (carleton instance)

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?

@rye rye self-assigned this Aug 11, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant