People know a lot about docker

Computer Games
#18

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
#19

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
#20

Yup. Those commands are not needed with my instructions since those are for restoring a mongo database, which we don’t have

1 Like
#21

//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
#22

Spam filter wasn’t happy about a new user posting multiple links to an external domain. I’ve restored them for you.

3 Likes
#23

(I’ve moved you up a trust level to let you post more freely)

3 Likes
#24

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
#25

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
#26

That’s how \ displays in my cmd line. Not sure why.

1 Like
#27

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
#28

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
#29

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
#30

Yeah the font was the cause of the ¥. Error is still there after that though.

1 Like
#31

I feel like I’ve just stumbled into a software stand-up at work…

6 Likes
#32

When I opened this can of worms I knew you would all be amazing.

4 Likes
#33

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
#34

This is exactly the issue, and a near-complete explanation for what’s happening.

I think I have a workaround. Standby

5 Likes
#35

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
#36

Fetched your commits. Got this error on the docker exec -it shintolin-1_shintolin3_1 bash step- Daemon Error - Album on Imgur
There was this in docker- CONTAINERSAttaching to shintolin-1_shintol - Pastebin.com

If the problem is just Windows and everything works in Linux I’m willing to change my OS. Had been thinking about it anyways because I don’t want to move to Windows 11.

#37

No worry. You don’t need to be in the same exact container, actually.

docker-compose run shintolin3 bash will get you a prompt that you can run that command from

After you do that and run the bootstrap-production script, exit from the container shell and then restart the whole stack:

docker-compose down
docker-compose up -d