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

08/18 ; Status update & next steps #1

Open
tony-shannon opened this issue Aug 9, 2018 · 1 comment
Open

08/18 ; Status update & next steps #1

tony-shannon opened this issue Aug 9, 2018 · 1 comment

Comments

@tony-shannon
Copy link
Member

tony-shannon commented Aug 9, 2018

Background to this issue: see here
RippleOSI/RippleOSI-General-Issues-Ideas#1

Hi Marcus @pacharanero
Can you update on progress here with suggested next steps, split by component, PT, QEWD, EtherCIS and then their combination (via Docker compose) towards NHSHackDay ease of setup
thanks
Tony

@pacharanero
Copy link
Contributor

pacharanero commented Oct 10, 2018

status update 2018.10.10

  • Pulsetile is now dockerized and has its own Dockerfile from which local or remote builds can be made (see PR and Issue
  • We are hoping to use Webpack's config settings to proxy all calls to api/ to the QEWD server (see separate issue here
  • QEWD was already dockerized but required considerable orchestration work in Docker-Compose to automatically set up and run the 5 parallel QEWD microservices. This work is now done.
  • EtherCIS had a few Docker images but none were automated builds, they were simply uploaded 'snapshots' of someone's personal image build (which I have a hard time trusting the security of - literally anything could have been installed and you would have to dig around in the Docker 'filesystem layers' to find out what)
  • I have used the work done by Seref, Rob (Dyke), and alessfg to separate out the two Dockerfiles into separate repositories, one for the server and one for the database
  • This means that Docker Hub can now make automated builds of each from their public Dockerfiles, which means it's easier to see what went into the images.
  • The whole thing is wrapped in a Vagrant virtual machine, which provides maximum portability and familiarity for the average developer. Inside the VM the Docker magic happens.
  • We are also working on a virtual machine with a graphical interface so that those who want to do their actual development inside the VM can do so. This will use all the previous work so requires very little additional effort.

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

2 participants