Docker containers?

[hospitalrun]

Docker containers?

[techthumb]

Has there been work done on this front?

I'm considering dockerizing the frontend app as mentioned in HospitalRun/hospitalrun-frontend#407

[codecounselor]

Hey @turboMaCk - I joined the project a while back and never really amounted to much :) but I've been playing with Node lately on another venture and just rigged up Vagrant. Back when I was setting up hospital run I wrote a pretty rudimentary script for os x, but if the hospital run gang has a desire for one of the common vagrant boxes (i.e. ubuntu) I'd be happy to help you or someone else work through the minor issues I just did.

While not precisely what you'd want, this vagrant file and shell script might be a good starting point: https://github.com/featureguardian/fg-config/tree/master/vagrant

[turboMaCk]

Hello @codecounselor
For me Docker have one big advantage over Vagrant. You can use it to ship and manage production environment so in fact whole deploy process for end user should be just setting something like docker-compose.yml by example and running docker run hospitalrun/production and whole infrastructure will be build and.

[filipesperandio]

I love Docker and would like to help on this.
What is the current approach for production deployment?

[jkleinsc]

@filipesperandio we are looking at 1.0 as an initial public release so right now there isn't a particular approach for production deployment. In the hospitals we are piloting in, we are just pulling straight from git.. not a long term solution, but for the handful of deploys it is what we are doing for now.

[filipesperandio]

@jkleinsc Is the internet connection reliable enough on those institutions (so that we could use a cloud solution for the servers) or is it the idea to host the server from within the local network moving forward?

[jkleinsc]

@filipesperandio because couchdb lends itself well to replication, in our hospitals our deployment plan is to host a server in the local network which replicates to a cloud server. This gives us redundancy/backups as well as a way of accessing data outside the hospital. The reality is, HospitalRun can work either way and in theory you could even run serverless if you didn't care about backups.

[filipesperandio]

@jkleinsc Cool. I am trying to better understand the environments so I can help with deployment strategies.
Is it usual to have a single computer in those hospitals or a full network? I am thinking if once setup a server there will be some setup required for other computers to reach out to that one, like DNS and/or routing...

[jkleinsc]

@filipesperandio I think it could depend on the hospital. Our hospitals have a full network so there is a DNS server in the hospital which has an entry for the local hospitalrun server. We use the same dns name outside the hospital so it is seamless to users which server they are connecting to.

I think some of the hospitals who could use a solution like this will have very little IT support to setup/change DNS, so if there are ways we can make this easier to deploy that would be great.

[turboMaCk]

This is why I think it might be useful to use docker-compose as first class citizen for managing it. After all there can be just one yml file with just ENV var and linking for all containers. Different scenario => different docker-compose.yml.

[filipesperandio]

@turboMaCk I like the idea too and I can help building up the docker images.

The simplest deployment strategy from my perspective, though, would be not to host anything within the hospitals' network and use Heroku or AWS for that so all infrastructure management would be handled by us, but this solution require the hospitals to rely on good internet connection.

[turboMaCk]

I think for now we can focus mainly on dev env. Than we will have much better experience about how is it stable, how it scales and based on that experience we will be able to made better decision what can we will be the best production maintenance.

I'll start with simple dev containers with mounting pwd (with source code) in "Vagrant like" way. Btw I made container which should be helpful for fronted. The idea is that developing cross stack should be much simpler. Think about running both via docker-compose with proxy. Than you will be able to test FE against FE with no pain at all.

This is that container: https://hub.docker.com/r/turbomack/ember-test-container/

[filipesperandio]

👍

[turboMaCk]

I believe not. At least not by me. I have some health problems for past few months so I better try to relax. Ask @jkleinsc but I think it would be awesome if you can push this forward.

[filipesperandio]

@techthumb I was planning to tackle that myself soon but didn't get the time to do so yet. Wanna work together on that?

[turboMaCk]

btw feel free to use this container and send PRs if any changes are required https://github.com/turboMaCk/ember-test-container I'll accept them asap.

Btw. Dont try tu build that image from repo.. Compilation of phatom.js from source can take up to 10 hrs.

[techthumb]

@turboMaCk I hope that you feel better soon. I'll look at that repo & try to make sense of it

@filipesperandio Yes! Let's.

Very basic, but this is what I've got so far: techthumb/hospitalrun-frontend@56ddfe0

[turboMaCk]

I think there is no need to have ZSH and OH-MY-ZSH directly in that container. In usual work flow you access all of this from outside of a container via docker run cmd. What you need is phantom.js for tests. I think you can go with my container for running ember + add another one for couchdb and build only docker-compose file for start whole cluster.

[techthumb]

@turboMaCk I agree with not installing ZSH & OH_MY_ZSH.

I'm keen to base the image off Alpine Linux.

I am trying to get a workflow working for both, dev & deploy.
It seems like a lofty goal though.

I am going to focus on dev workflow for now.

What are your thoughts @filipesperandio ?

[techthumb]

I've got a build happening within docker: https://travis-ci.org/techthumb/hospitalrun-frontend/builds/122688998

However, I'm running into failures & timeouts.

I'm investigating.

[turboMaCk]

You're building docker container in build step? This is insane. You want tests to run as fast as possible. Pull that container from docker hub and just run tests inside of it.

[techthumb]

Running the tests in the container gives us dev & prod parity. Hence, I'd be willing to pay that cost.

Also, caching node_modules will give us the speed gains we need.

[visualjeff]

I think you might want to build the app then copy into the docker image the final ember dist directory. Then use node to with a small script to serve up the final product. WIth CouchDB I've always fronted it with nginx so as to provide TLS support for secure connections. The two docker images would be managed by docker-compose. The goal would be to keep them fairly small in size. Each container under 300mb. I've built both types of images and will be will to help. I have docker images for another project that basically accomplish this task. Happy to share.

[pierreozoux]

Any updates on that issue? I might help as well.

Let me know!

[visualjeff]

I don't have any updates related to this particular issue. I use docker and docker compose at work (on node and ember projects) so maybe I can help? Let me know if I can be of any assistance.

[techthumb]

techthumb/hospitalrun-frontend@dbc5c8a

I've got it working, but it is very slow.

[hsorellana]

is this issue being worked on?? i'm new to the project but with a lot of hope in making contributions.

[jkleinsc]

This issue was resolved with pr #41