fix: Docker pip install - create directory for `/requirements/`

[tgrrr]

error message: copy failed stat .../requirements: no such file or directory error line: https://github.com/codebuddies/backend/blob/675ef04f70930f9951b2638a22cd1aa7a1a460c3/project/Dockerfile#L7 slack thread: https://codebuddies.slack.com/archives/C04BRN86J/p1587889877253000

[codecov[bot]]

Codecov Report

Merging #137 into master will not change coverage. The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #137   +/-   ##
=======================================
  Coverage   81.44%   81.44%           
=======================================
  Files          29       29           
  Lines         469      469           
=======================================
  Hits          382      382           
  Misses         87       87           

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update f83c2d0...a16a167. Read the comment docs.

[lpatmo]

Thanks for looking into this, @tgrrr :)

Since I am a little worried about the longevity of that Slack URL due to the 10K messages limit, here's a paste of the error message screenshot when I tried deploying project/Dockerfile onto dockerhub.com:

https://github.com/codebuddies/backend/blob/675ef04f70930f9951b2638a22cd1aa7a1a460c3/project/Dockerfile#L7

Chris:

Yep. Dockerhub is for publishing a docker container
Docker-compose is for describing multi-container applications
cb-backend is an application made up of 5 containers:
- db
- app
- web
- adminr
- webhog
with a docker-compose config to glue them all together.
I think probably what you're doing is just trying to publish the app container to DockerHub, but that isn't enough to run the whole backend app.
If you published all 5 containers, then the frontend user would be able to grab them all and compose them, but I think that would make things more complicated than just using the backend repo, not simpler: You're basically putting it on the frontend dev to write their own docker-compose instead of using the one that already exists.
The advantage you might gain from publishing to dockerhub might be that you could publish stable releases of the backend so frontend doesn't have to track dev, but I'm not sure the project is at a stage where that has value yet.

[lpatmo]

So my understanding right now is that: 1/ If this change works and I'm able to deploy to dockerhub.com, I'll be deploying an image that contains the app only.

2/ Afterwards, I'll have to set up a few other things in DigitalOcean -- including the postgres database (required), adminer (optional but nice to have), nginx (required), and mailhog (required since we'll need to send transactional emails)

3/ Alternatively, is there a way I can deploy docker-compose directly to a DigitalOcean droplet, under a "production" .yaml file

@chris48s and @billglover -- would appreciate your input as well, when you have time -- especially since I vaguely remember watching @billglover deploy on DigitalOcean easily using our current set-up but I've completely forgotten the context. Either that or I didn't take careful-enough notes in the cbv3 notes doc 😓

[tgrrr]

3/ Alternatively, is there a way I can deploy docker-compose directly to a DigitalOcean droplet, under a "production" .yaml file

It's possible, see:

• Docker-compose production

Docker Compose from development to production:

# docker-compose.yml
services:
  my-service:
    build:
      context: .
    image: private.registry.mine/my-stack/my-service:${MY_SERVICE_VERSION:-latest}
    environment:
      API_ENDPOINT: ${API_ENDPOINT:-https://production.my-api.com}

And

# docker-compose.override.yml
services:
  my-service:
    ports: # This is needed for development!
      - 80:80
    environment:
      API_ENDPOINT: https://devel.my-api.com
    volumes:
      - ./:/project/src

Though, my preference is to differentiate between dev/test/production using CircleCI or another CI

@lpatmo do we have a test and production droplet at Digital Ocean?

[billglover]

There is a closed PR somewhere that has a staging/production deployment in it. This may give you some pointers (although it had staging and prod on the same host).

It also used GitHub rather than DockerHub as the image repository.

I’ll try and find some time this evening to find it and cross reference here. Even if the image has changed, the deployment steps should be similar.

On 29 Apr 2020, at 09:01, Phil notifications@github.com wrote:

 3/ Alternatively, is there a way I can deploy docker-compose directly to a DigitalOcean droplet, under a "production" .yaml file

It's possible, see:

Docker-compose production Docker Compose from development to production:

docker-compose.yml

services: my-service: build: context: . image: private.registry.mine/my-stack/my-service:${MY_SERVICE_VERSION:-latest} environment: API_ENDPOINT: ${API_ENDPOINT:-https://production.my-api.com}

And

docker-compose.override.yml

services: my-service: ports: # This is needed for development!

• 80:80 environment: API_ENDPOINT: https://devel.my-api.com volumes:
• ./:/project/src Though, my preference is to differentiate between dev/test/production using CircleCI or another CI

@lpatmo do we have a test and production droplet at Digital Ocean?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[lpatmo]

There is a closed PR somewhere that has a staging/production deployment in it.

lol, I cannot believe I forgot about https://github.com/codebuddies/backend/pull/91/files -- didn't I even leave questions on it too?? Oof, I don't think my mind was on it last month, sorry. (Thank youuu)

It also used GitHub rather than DockerHub as the image repository. I see, looks like the image was hosted on registry: docker.pkg.github.com

Questions: 1/ Should I re-open https://github.com/codebuddies/backend/pull/91/files? 2/ The image contains only the app itself, right? And from my understandiing, building and publishing the image to github happens in .github/workflows/stage.yaml starting on line 15 3/ When you last explored this @billglover, how did you deploy to DigitalOcean without the files in https://github.com/codebuddies/backend/pull/91/files being merged? (My guess is you told DO about a specific branch, maybe?)

@lpatmo do we have a test and production droplet at Digital Ocean?

I'll create a new droplet on DigitalOcean for test/staging purposes (think we can hold off from having a production droplet)

[billglover]

Questions: 1/ Should I re-open https://github.com/codebuddies/backend/pull/91/files?

I wouldn't re-open it, I think enough has changed in how we are building images. It also feels like we are considering staging / prod being separate for now. This simplifies things.

2/ The image contains only the app itself, right? And from my understandiing, building and publishing the image to github happens in .github/workflows/stage.yaml starting on line 15

The image did contain only the app (and I think static content). I'm not sure if we settled on how to serve these. Your understanding is correct, the build happens here: https://github.com/codebuddies/backend/pull/91/files#diff-a819d86be9df6d3f48384cce6f9c22a3R15-R25

3/ When you last explored this @billglover, how did you deploy to DigitalOcean without the files in https://github.com/codebuddies/backend/pull/91/files being merged? (My guess is you told DO about a specific branch, maybe?)

I changed the trigger on the workflow definition to run on every push to my branch. It took quite a few attempts to get things to run smoothly. I then modified the trigger to run only on master. I suspect this is a behaviour that we'll want to tweak over time. But this is difficult to debug until something is up and running.

I used the Docker template droplet and it required very little tinkering on the droplet itself. I don't think this was anything more than adding a user so we weren't deploying as root and then modifying the firewall. Documentation on the Wiki

[lpatmo]

Sweet, I forgot you documented on the wiki! Thank you! :)

[billglover]

Please shout if anything isn’t clear.

[lpatmo]

@billglover Thank you so much! Will do. :) I think I have a much better understanding of this now; will poke at it over the next few days, and excited to add some additional docs about the process too! (Your docs on the wiki are excellent... I'm just itching to add some screenshots and take some personal notes as well, lol)

@tgrrr Would it be all right if we closed this PR and moved this discussion to an issue? I'll open up an issue about deploying to staging, and link to my deployment notes and ask any additional questions there.

[tgrrr]

You're right, this conversation does belong with a test/production issue @lpatmo.

Does this PR solve the bug? Ie. Do you mean to merge the PR and close, or just close it?

[lpatmo]

@tgrrr Sorry, I meant I will close it :D This PR doesn't solve the bug, since my approach was all wrong -- I shouldn't have been trying to upload this file to either Dockerhub or Github Actions at all since it is a local file.