A really bad one……
2 Likes
So it wouldn’t be the cli for either of these? They’re both tagged mongo while the top one ‘shintolin’ does not have the option of opening a cli window. Sorry for all the dumb questions, I don’t have any experience with Docker prior to this.
If you run the docker-compose file, you should get two containers: shintolin_shintolin3_1 and shintolin_shintolin3-mongo_1. I’m not sure how you are launching the docker-compose file, so I can’t give guidance on how to get both containers.
In my updated docker-compose file, I have a 3rd container that launches the clock.js task that runs all the cron jobs.
My modified files are here:
Be aware that for the Mongo DB, I’ve mapped the database data path in the container to a host folder so that the database can survive stack creation/deletion events. In this case, it’s a folder called mongodb in the parent folder for the git project root.
├── mongodb <------ database data path
└── shintolin
├── apps
├── bin
├── commands
├── data
├── node_modules
├── queries
└── test
1 Like
I think the problem may be that I haven’t run the docker-compose.yml file then? I’d just been doing-
docker-compose up shintolin3-mongo
docker-compose run shintolin3-mongo bash
Then trying to run bootstrap-production.
1 Like
Yup. Those commands are not needed with my instructions since those are for restoring a mongo database, which we don’t have
1 Like
//https://imgur.com/gallery/4oqudtH
(Wouldn’t let me post the link for some reason)
Seemed to be working but now I’m running into a different missing file.
So I would use those commands to start the database back up after having created the database and shutting it down? With your edits to make the cron jobs run in a container it’d no longer be necessary to host it using Mongo Atlas right? Thank you so much for all this help. I’ve been trying to figure this out for awhile.
1 Like
Spam filter wasn’t happy about a new user posting multiple links to an external domain. I’ve restored them for you.
3 Likes
(I’ve moved you up a trust level to let you post more freely)
3 Likes
I’m not sure what that error is. Looks like perhaps a text encoding issue within the container (which is weird and kinda opposite the expectation of container-based deployment). The resolution of the images is pretty poor, so it’s hard to tell for certain.
I don’t currently have a Docker for Windows environment running anywhere but I may be able to spin one up in a few hours to see if it’s a platform issue when running on windows.
1 Like
Can you explain what the ¥ character is on your system/terminal?
It crops up in that “missing file name” in the last screenshot, and like pillbox I initially though that an encoding problem might be behind that seemingly bad filename – but then I looked at the earlier screenshots and that same character seems to be all over the place for your local system.
2 Likes
That’s how \ displays in my cmd line. Not sure why.
1 Like
We used to have that happen all the time at work. I think it is due to some combination of fonts and language settings (Japanese overrides the Unicode backslash with the Yen symbol).
I believe they should still be interpreted correctly because they are the same Unicode character, although I am far from an expert on using the command line.
3 Likes
Huh. I did have both English and Japanese set as languages. No idea why. Removed Japanese and restarted. Still getting the same error and the ¥ are still there and replacing \ in the cmd line.
1 Like
Could be that Japanese changed the default command line font? If you right click the Command Prompt window title, you should be able to select properties and go to the font tab. I think it is MS Gothic that turns backslashes into Yen symbols? If you switch to Consolas or Lucida Console they should go away. If that wasn’t the problem then I’m afraid that’s the extent of my knowledge.
I doubt that will help with the error, but you never know.
3 Likes
Yeah the font was the cause of the ¥. Error is still there after that though.
1 Like
I feel like I’ve just stumbled into a software stand-up at work…
6 Likes
When I opened this can of worms I knew you would all be amazing.
4 Likes
Ah, so it’s actually saying that it’s failing to find:
node_modules/coffeescript/bin/coffee\r
I strongly suspect that \r will represent a carriage return.
So it should be looking for coffee, but a carriage return has gotten into the string for the path it’s using. As everything other than the null character is (strictly) allowed in filenames, a file by that name isn’t invalid – but of course doesn’t actually exist.
I can’t be confident about how that’s happening, but as you’re running on Windows which has always liked CRLF rather than just LF for line endings, I’m assuming it’s related. Perhaps that’s a locale feature, and hosting on Windows affects that? I’m merely speculating at this point.
Have a look at how that file path gets generated, for starters.
3 Likes
This is exactly the issue, and a near-complete explanation for what’s happening.
I think I have a workaround. Standby
5 Likes
I’ve fiddled with the .gitattributes file in the repo that should heavy-handedly force LF line-endings. Bad for anyone doing native Windows deployment, but good for anyone using Windows git.exe to pull the files for use with (linux) docker containers.
Not exactly sure if you can just git pull to get the complete changes because line-endings in git are actually a bit magical.
I also update the README.md with new instructions. Completely ignore the original instructions.
1 Like