Open znmeb opened 6 years ago
Tested on Linux - works fine. Next up is a re-test with PowerShell on Windows 10 Pro / Docker for Windows and a README for the process, since it's not the same as on Linux or a Mac.
After my testing on Windows, which failed, because the volume
mounting of "." into the API container /code
wasn't working. So I've built a one-step development environment creator that doesn't need to mount host files into a container. See README-onestep.md
.
I've tested it on Linux and will test it on Windows tomorrow. There's one piece left to do: design an iteration workflow and supporting scripts. The scheme I'm thinking of is:
psql
, and the code can be edited via docker exec
. docker cp
commands will fetch the code.Tested and working on Linux host using docker-machine
/ VirtualBox connection. Everything works.
@znmeb what was jessie used for?
@mxmoss There were some files that images built on Debian "jessie" used - now that both images come from "stretch" they're not needed any more.
Latest test update - works on Windows 10 Pro from WSL Ubuntu using the Disaster Resilience backup file I have salted away. I've added the .env file I used to the repo.
@mxmoss is testing on Windows 10 Home with Docker Toolbox. So far he's just run into line ending problems.
Tested on Windows 10 Pro / Docker for Windows from a git bash
window - works.
Question: does staticfiles
need to be in version control? It's built in the container and I'm copying it down to the repo, but it's in .gitignore
so it doesn't get version-controlled. Should it be?
Status update: This pull request addresses two issues
The only test that hasn't been completed is testing whether the new code works on Windows 10 Home, which uses the Docker Toolbox / VirtualBox method. And I'd like someone to test the new one-step builder on a Mac before we merge this.
this will take a little time to get through. 2 questions from quick glance:
What is the recommended workflow and stack for running the images on Windows 10 Pro?
the theme related .env files, the idea is to provide these as more ready to go samples within the repo?
I've actually been thinking about this subject... Incidentally, I suppose I also came to the same conclusion as Ed independently, because I also just put a disaster.env
file into the root of the disaster-resilience-backend
repo. It has the postgres values set to the correct values to match my disaster.backup
that gets restored. The motivation was that when a user first clones a backend repo, they must cp the sample.env
to the correct filename and then set three of the values inside of the file. Otherwise, or if they are unaware or don't know the correct values, they get errors when building the image. So instead of greeting the user with the necessity of getting all that correct and the probability of not doing so, I thought it would be easier if I just provided the file and probable values in an example file (kind of like the sample.env
does). The values should match the settings in the postgres DB backup file that the repo is likely to use, in my case the disaster.backup
with postgres
as DEVELOPMENT_POSTGRES_OWNER/_USER
and disasater
as DEVELOPMENT_POSTGRES_NAME
.
I suggest that we consider some type of mechanism like this that relieves the user of the burden of the necessity of having to set up the database settings, where possible.
cool, we do want to make it easy as possible for folks to get up and running easily, so sounds good. i just wasn't 100% sure why, and there is nothing in readme/docs.
I guess documenting the intention of the onestep, providing link from main readme to that one might be good?
Yeah - more documentation is always good. Has anyone tested this branch on a Mac? I want to make sure forcing the line endings to Linux mode didn't break a Mac.
This line ending stuff is tricky - I probably should re-code it so only files that run in the container are forced to Linux mode. Also, separate the scripts into a folder that runs in the container and a folder that runs in the host.
I feel that by including the default.envs we can remove a significant hurdle to the first time quickstart application generation and build/start process.
No I don't have any access to Mac environments.
@znmeb What example .env files do you currently have? I have one that works for disaster.backup, but not any others. Also related - for the PRODUCTIONPOSTGRES secret I removed their values, leaving them blank, before I checked mine in.
I have one for each of our two databases ... One is in there now
The project seems to be progressing well without this pull request - @nam20485 @mxmoss @bhgrant8 should I cancel it and close the issues "wontfix?""
I vote for cancelling it. Because it seems like its not necessary, and in looking at the commits, it appears to be a lot of change for something that is not necessary.
Tested on Windows from PowerShell on the built-in sample database ("dead_songs") using manual
docker-compose -f build
anddocker-compose -f up
. Don't merge until I have a chance to test it on Linux!