[deploy] plan for fling.work ecosystem

[ortonomy]

A deployment plan for fling.work app ecosystem so we can put it through CI on codeship and then deploy to heroku.

Questions:

1. Do we containerize the whole thing?
2. Do we need to? How does

heroku organize the following react components

Components of the system

• postgreSQL db
• postgraphql node process (as library in express app) running on localhost:3001/graphql
• worker node process (as single .js script)
• react.js app
• nginx to serve front-end, and direct to api

DoD

• deployment plan updated on wiki: https://github.com/ortonomy/fling-server/wiki/Deployment-plan-for-fling.work-ecosystem
• questions answered
• PR with code for CI / deployment integration

[Jskobos]

Containers or no, sounds like it would be worth it to start on some kind of CI pipeline. e.g. Travis can run every time a merge to master is made, run the test suites, run a build pipeline with Babel (Gulp? Webpack?), then either rsync the resulting build to the server or else containerize it, push it to Docker Hub, and then the server(s) and/or any developers can pull and run the new containers.

[ortonomy]

Yeah, I agree. Coderbunker has a codeship team which we can use, so thinking of using that as CI.

The react app I think comes with a build step already built in, so we just then need to rsync or ssh the content to whatever server.

Once you've containerized it, do we need to put it on docker hub, or can we copy the new containers directly the server? What does docker hub get us?

[cwkeam]

What I am familiar with is saving the script that creates the container, rsync-ing the script to the server, and running the script in the server to build the container there. You would want a way to access the image first, which could be done using docker hub or by running a script that builds it.

What I usually do is having a script that, by running it, rsyncs all the content in the local computer to the server. Then I would manually stop the currently running container then run the script that creates the container, updating whatever content the server is serving.

[Jskobos]

Yeah, a Dockerfile works too. Docker Hub makes it easy for anyone to pull the containers and run them, but building from a publicly available Dockerfile is pretty much the same thing.

…

On Mon, Mar 5, 2018 at 10:16 AM, Chan Woo Kim ***@***.***> wrote: What I am familiar with is saving the script that creates the container, rsync-ing the script to the server, and running the script in the server to build the container there. You would want a way to access the image first, which could be done using docker hub or by running a script that builds it. [image: screen shot 2018-03-05 at 11 12 24 pm] <https://user-images.githubusercontent.com/8522953/36982588-2b986de4-20cb-11e8-84c8-e906e3df9dba.png> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABjIA0Ly08nqv5z89BFMweqAaYVerVKGks5tbVbbgaJpZM4Sb2Xd> .

[cwkeam]

But don't you pull Docker images, not containers, from Docker Hub? Same case for building it from a Dockerfile. I wasn't talking about building the image from a Dockerfile from the remote server, but rather having an existing image (Docker Hub would be convenient) and containerizing whatever would be there on the server that we need.

How it's one thing to have a Docker image in Docker Hub: https://hub.docker.com/r/jupyter/datascience-notebook/

But another thing to build a container in it:
docker run -it --rm -p 8888:8888 jupyter/datascience-notebook

Especially in my example, it's actually more quite flexible because the volume is specified in the script that builds the container, not in the Dockerfile, attaching it to the container, not the image. That would make it so that we use the same image every time that gives us our ability to use PostgreSQL, Node.js, and more, but just stop and re-run the script that builds the container every time we make a merge to master, instead of rebuilding the image every time (this would take ages).

[Jskobos]

Yeah, Docker hub is just convenience. *docker run -d nginx* and you're done for example, it'll pull and launch the official NGINX image in one go. But again, public Dockerfile is basically the same thing.

…

On Mon, Mar 5, 2018 at 10:53 AM, Chan Woo Kim ***@***.***> wrote: Wait, but don't you pull Docker images, not containers, from Docker Hub? Same case for building it from a Dockerfile. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABjIA9x4_T2XZsV4w3XDoUnNpC7HZMypks5tbV9zgaJpZM4Sb2Xd> .