build(docker): local deployment #1263
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This is obviously way too big. We can get it smaller by e.g. de-duplicating node dependencies. |
roschaefer
commented
Jun 25, 2024
| RUN rc-update add pm2 boot | ||
| RUN rc-update add mariadb boot | ||
|
|
||
| RUN git clone --depth 1 https://github.com/dreammall-earth/dreammall.earth.git /var/www/localhost/htdocs/dreammall.earth |
There was a problem hiding this comment.
This is a little silly. With a .dockerignore taking out node_modules we could COPY the content of the entire repository into the docker image.
roschaefer
force-pushed
the
reproducable-deployment
branch
2 times, most recently
from
3acd282 to
c461993
Compare
roschaefer
changed the title
Motivation ---------- On the weekend we had a downtime on production because `nginx` configurations got out of sync with the code in newer releases. To prevent this and further downtimes I suggest to check in our deployment configuration and make it *reproducible*. This PR is an attempt to create a docker container that behaves as similar as possible to production and can be used as a sandbox for changes to our deployment configuration. Read about infrastructure as code: https://en.wikipedia.org/wiki/Infrastructure_as_code How to test ----------- 1. `cd deployment` 2. `docker build . --tag dreammall-deployment` 3. `docker run -it -p 8080:80 dreammall-deployment sh` .. and wait 4. Following services are running: * http://localhost:8080/ * http://localhost:8080/api * http://localhost:8080/docs 5. Be amazed
roschaefer
force-pushed
the
reproducable-deployment
branch
from
c461993 to
891a6e2
Compare
|
The only missing part here is the reverse proxy that forwards different stages, e.g. |
Elweyn
reviewed
Jun 27, 2024
There was a problem hiding this comment.
I had a problem with backend.
When I go on localhost:8080 and click on sign in I get on http://localhost:3000/signin instead of the frontend URL. (In presenter/.env it is defined to localhost:3000)
Except this it works. Goes in the right direction
Elweyn
requested changes
Jun 27, 2024
Comment on lines
+24
to
+26
| RUN cp backend/.env.dist backend/.env | ||
| RUN cp presenter/.env.dist presenter/.env | ||
| RUN cp frontend/.env.dist frontend/.env |
There was a problem hiding this comment.
Here we will need other values than the default ones
There was a problem hiding this comment.
This is actually a paint point that becomes visible through this PR. What are the right values for production? Is it documented anywhere?
roschaefer
added a commit
that referenced
this pull request
Jun 27, 2024
Context ------- There was a similar PR #1263 attempting to do the same with docker. I was running into isolation issues with docker (setting hostname not allowed in the container and some system folders are read-only) and learned that for this use case, an actual hypervisor would be better and vagrant is a conventional tool to set up these virtual machines. Motivation ---------- On the weekend we had a downtime on production because `nginx` configurations got out of sync with the code in newer releases. To prevent this and further downtimes I suggest to check in our deployment configuration and make it *reproducible*. This PR is an attempt to create a virtual machine that behaves as similar as possible to production and can be used as a sandbox for changes to our deployment configuration. How to test ----------- 1. Install [Vagrant](https://www.vagrantup.com/) on your machine 2. `cd deployment/local-testing` 3. `vagrant up` .. and wait 4. Following services are running: * http://localhost:8080/ * http://localhost:8080/api * http://localhost:8080/docs 5. Be amazed
roschaefer
added a commit
that referenced
this pull request
Jun 27, 2024
Context ------- There was a similar PR #1263 attempting to do the same with docker. I was running into isolation issues with docker (setting hostname not allowed in the container and some system folders are read-only) and learned that for this use case, an actual hypervisor would be better and vagrant is a conventional tool to set up these virtual machines. Motivation ---------- On the weekend we had a downtime on production because `nginx` configurations got out of sync with the code in newer releases. To prevent this and further downtimes I suggest to check in our deployment configuration and make it *reproducible*. This PR is an attempt to create a virtual machine that behaves as similar as possible to production and can be used as a sandbox for changes to our deployment configuration. How to test ----------- 1. Install [Vagrant](https://www.vagrantup.com/) on your machine 2. `cd deployment/local-testing` 3. `vagrant up` .. and wait 4. Following services are running: * http://localhost:8080/ * http://localhost:8080/api * http://localhost:8080/docs 5. Be amazed
roschaefer
added a commit
that referenced
this pull request
Jun 27, 2024
Context ------- There was a similar PR #1263 attempting to do the same with docker. I was running into isolation issues with docker (setting hostname not allowed in the container and some system folders are read-only) and learned that for this use case, an actual hypervisor would be better and vagrant is a conventional tool to set up these virtual machines. Motivation ---------- On the weekend we had a downtime on production because `nginx` configurations got out of sync with the code in newer releases. To prevent this and further downtimes I suggest to check in our deployment configuration and make it *reproducible*. This PR is an attempt to create a virtual machine that behaves as similar as possible to production and can be used as a sandbox for changes to our deployment configuration. How to test ----------- 1. Install [Vagrant](https://www.vagrantup.com/) on your machine 2. `cd deployment/local-testing` 3. `vagrant up` .. and wait 4. Following services are running: * http://localhost:8080/ * http://localhost:8080/api * http://localhost:8080/docs 5. Be amazed
|
closed in favour of #1272 |
roschaefer
added a commit
to roschaefer/dreammall.earth
that referenced
this pull request
Jun 27, 2024
Context ------- There was a similar PR dreammall-earth#1263 attempting to do the same with docker. I was running into isolation issues with docker (setting hostname not allowed in the container and some system folders are read-only) and learned that for this use case, an actual hypervisor would be better and vagrant is a conventional tool to set up these virtual machines. Motivation ---------- On the weekend we had a downtime on production because `nginx` configurations got out of sync with the code in newer releases. To prevent this and further downtimes I suggest to check in our deployment configuration and make it *reproducible*. This PR is an attempt to create a virtual machine that behaves as similar as possible to production and can be used as a sandbox for changes to our deployment configuration. How to test ----------- 1. Install [Vagrant](https://www.vagrantup.com/) on your machine 2. `cd deployment/local-testing` 3. `vagrant up` .. and wait 4. Following services are running: * http://localhost:8080/ * http://localhost:8080/api * http://localhost:8080/docs 5. Be amazed
roschaefer
added a commit
to roschaefer/dreammall.earth
that referenced
this pull request
Jun 27, 2024
Context ------- There was a similar PR dreammall-earth#1263 attempting to do the same with docker. I was running into isolation issues with docker (setting hostname not allowed in the container and some system folders are read-only) and learned that for this use case, an actual hypervisor would be better and vagrant is a conventional tool to set up these virtual machines. Motivation ---------- On the weekend we had a downtime on production because `nginx` configurations got out of sync with the code in newer releases. To prevent this and further downtimes I suggest to check in our deployment configuration and make it *reproducible*. This PR is an attempt to create a virtual machine that behaves as similar as possible to production and can be used as a sandbox for changes to our deployment configuration. How to test ----------- 1. Install [Vagrant](https://www.vagrantup.com/) on your machine 2. `cd deployment/local-testing` 3. `vagrant up` .. and wait 4. Following services are running: * http://localhost:8080/ * http://localhost:8080/api * http://localhost:8080/docs 5. Be amazed
roschaefer
added a commit
that referenced
this pull request
Jun 27, 2024
Context ------- There was a similar PR #1263 attempting to do the same with docker. I was running into isolation issues with docker (setting hostname not allowed in the container and some system folders are read-only) and learned that for this use case, an actual hypervisor would be better and vagrant is a conventional tool to set up these virtual machines. Motivation ---------- On the weekend we had a downtime on production because `nginx` configurations got out of sync with the code in newer releases. To prevent this and further downtimes I suggest to check in our deployment configuration and make it *reproducible*. This PR is an attempt to create a virtual machine that behaves as similar as possible to production and can be used as a sandbox for changes to our deployment configuration. How to test ----------- 1. Install [Vagrant](https://www.vagrantup.com/) on your machine 2. `cd deployment/local-testing` 3. `vagrant up` .. and wait 4. Following services are running: * http://localhost:8080/ * http://localhost:8080/api * http://localhost:8080/docs 5. Be amazed
roschaefer
added a commit
that referenced
this pull request
Jun 27, 2024
Context ------- There was a similar PR #1263 attempting to do the same with docker. I was running into isolation issues with docker (setting hostname not allowed in the container and some system folders are read-only) and learned that for this use case, an actual hypervisor would be better and vagrant is a conventional tool to set up these virtual machines. Motivation ---------- On the weekend we had a downtime on production because `nginx` configurations got out of sync with the code in newer releases. To prevent this and further downtimes I suggest to check in our deployment configuration and make it *reproducible*. This PR is an attempt to create a virtual machine that behaves as similar as possible to production and can be used as a sandbox for changes to our deployment configuration. How to test ----------- 1. Install [Vagrant](https://www.vagrantup.com/) on your machine 2. `cd deployment/local-testing` 3. `vagrant up` .. and wait 4. Following services are running: * http://localhost:8080/ * http://localhost:8080/api * http://localhost:8080/docs 5. Be amazed
roschaefer
added a commit
that referenced
this pull request
Jun 30, 2024
Context ------- There was a similar PR #1263 attempting to do the same with docker. I was running into isolation issues with docker (setting hostname not allowed in the container and some system folders are read-only) and learned that for this use case, an actual hypervisor would be better and vagrant is a conventional tool to set up these virtual machines. Motivation ---------- On the weekend we had a downtime on production because `nginx` configurations got out of sync with the code in newer releases. To prevent this and further downtimes I suggest to check in our deployment configuration and make it *reproducible*. This PR is an attempt to create a virtual machine that behaves as similar as possible to production and can be used as a sandbox for changes to our deployment configuration. How to test ----------- 1. Install [Vagrant](https://www.vagrantup.com/) on your machine 1. `cd deployment/local-testing` 1. `vagrant up` .. and wait 1. Following services are running: - <http://localhost:8000/> - <http://localhost:8000/api> - <http://localhost:8000/docs> - <http://localhost:8080/> - <http://localhost:8082/> 1. Be amazed In the future we might want to use [Ansible](https://www.ansible.com/) for provisioning. We could run our playbooks against this virtual machine, too.
roschaefer
added a commit
that referenced
this pull request
Jul 1, 2024
Context ------- There was a similar PR #1263 attempting to do the same with docker. I was running into isolation issues with docker (setting hostname not allowed in the container and some system folders are read-only) and learned that for this use case, an actual hypervisor would be better and vagrant is a conventional tool to set up these virtual machines. Motivation ---------- On the weekend we had a downtime on production because `nginx` configurations got out of sync with the code in newer releases. To prevent this and further downtimes I suggest to check in our deployment configuration and make it *reproducible*. This PR is an attempt to create a virtual machine that behaves as similar as possible to production and can be used as a sandbox for changes to our deployment configuration. How to test ----------- 1. Install [Vagrant](https://www.vagrantup.com/) on your machine 1. `cd deployment/local-testing` 1. `vagrant up` .. and wait 1. Following services are running: - <http://localhost:8000/> - <http://localhost:8000/api> - <http://localhost:8000/docs> - <http://localhost:8080/> - <http://localhost:8082/> 1. Be amazed In the future we might want to use [Ansible](https://www.ansible.com/) for provisioning. We could run our playbooks against this virtual machine, too.
roschaefer
added a commit
that referenced
this pull request
Jul 1, 2024
Context ------- There was a similar PR #1263 attempting to do the same with docker. I was running into isolation issues with docker (setting hostname not allowed in the container and some system folders are read-only) and learned that for this use case, an actual hypervisor would be better and vagrant is a conventional tool to set up these virtual machines. Motivation ---------- On the weekend we had a downtime on production because `nginx` configurations got out of sync with the code in newer releases. To prevent this and further downtimes I suggest to check in our deployment configuration and make it *reproducible*. This PR is an attempt to create a virtual machine that behaves as similar as possible to production and can be used as a sandbox for changes to our deployment configuration. How to test ----------- 1. Install [Vagrant](https://www.vagrantup.com/) on your machine 1. `cd deployment/local-testing` 1. `vagrant up` .. and wait 1. Following services are running: - <http://localhost:8000/> - <http://localhost:8000/api> - <http://localhost:8000/docs> - <http://localhost:8080/> - <http://localhost:8082/> 1. Be amazed In the future we might want to use [Ansible](https://www.ansible.com/) for provisioning. We could run our playbooks against this virtual machine, too.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
On the weekend we had a downtime on production because
nginxconfigurations got out of sync with the code in newer releases.To prevent this and further downtimes I suggest to check in our deployment configuration and make it reproducible.
This PR is an attempt to create a docker container that behaves as similar as possible to production and can be used as a sandbox for changes to our deployment configuration.
Read about infrastructure as code: https://en.wikipedia.org/wiki/Infrastructure_as_code
How to test
cd deploymentdocker build . --tag dreammall-deploymentdocker run -it -p 8080:80 dreammall-deployment sh.. and wait