stupid docker creators. Why the fuck when something does not work it does no show errors. I had so much anger till idea came to head to ask on google does docker has logs and found it has - docker logs command. And I saw fucking errors and then I knew by them what to fix. Idiots, hide errors when runing docker-compose up, what are they smoking when creating docker.

And even after docker-compose up it showed done !! Done sounds as everthing went without fucking errrors!!!! But when running docker ps there was no such container! Because when running it - it was giving errors.

I don’t do much docker but that sound sensible to me.

It just starts the docket successfully, then something bad immediately happens after that and it shuts down.

@petergriffin no, it does not sound good, unless you want less people to be able to work with this so those people cost more and make projects more expensive to build.

@Angry-dev if you horribly fuck up your boot initialization on bare Metal, you will not get a fancy error message, the system simply resets and therefor boots again. Typical Bootloop stuff.

Except, a virtual Maschine can be configured to stay closed when the system resets. This is default behavior by docker as that’s what expected.

The docker Maschine started successfully, but did not boot properly.

It has nothing to do with docker and docker shouldn’t have special behavior for things that are like that since computers exist.

There are procedures like health checks to ensure an docker Container actually did fully start and continues to work over time.

Half of all docker image development is literally running the commands in a running container of your base image.

A Dockerfile is literally a step by step recipe on provisioning a "server".

Also, as long as you log everything to STDOUT you can see it via docker log.

If you don't see anything in your logs when you run your image, there's a good chance that your startup or init scripts are fucked.

@petergriffin "if you horribly fuck up your boot initialization on bare Metal, you will not get a fancy error message, the system simply resets and therefor boots again. Typical Bootloop stuff."

I do not know how things go on bare metals.

"It has nothing to do with docker and docker shouldn’t have special behavior for things that are like that since computers exist."

If somehing is like that since existance then it does not mean it is good.
If it has nothing to do with docker, then what it has to do with?

@sariel "If you don't see anything in your logs when you run your image, there's a good chance that your startup or init scripts are fucked."

Ok but I want to see that my scripts are fucked and what is wrong with them. Without need to call docker logs.

Calling docker logs is not that hard if you know such command exists but when you work rarely with docker it is hard to even think about that there is such command.

By default, "docker-compose up" stays in the foreground and you're able to see your logs. If you add "-d" (or whatever the daemonise flag is called), it will detach from the terminal and no longer show logs. The only moment where it makes sense to do this is right after the init script is started, because after that the next event that docker is guaranteed to receive is termination.

Did you use -d without understanding what it does?

Naturally, the init script can only fail after it's started, so that failure will happen after Compose returned control to your terminal and it will only be reported in the logs.

@Angry-dev I don't think you get it.

When your init script fails, it causes a full stack error and causes the entire chain to halt. You don't see the error because stdlib hasn't even completed yet.

Also, exactly what @homo-lorens said.

If you're using docker compose in daemon mode you won't see the logs come though docker compose.

You can always use docker-compose logs -f to follow the logs piped through compose though.

It sounds like to me you're frustrated because this is a new platform for you. Hang in there. Yes it's hard, but the benefits are huge.

I can work circles around the devs in my team because I can instantly have a development env spun up in minutes instead of days or hours. If I fuck it up, cull the container and start again.

I cannot stress how important it is to learn and understand containerization as a developer. It's literally going to cost you opportunities if you don't learn it.

@homo-lorens I used I knew it allows continue using terminal. If without -d, then cannot run another command in the same terminal. But I still expected it to show logs first, if it can show word "done", then I believe it should be able to show logs.

@Angry-dev You can use ^Z to move the current job to the background in Bash. That way you can run other commands but the Compose group remains connected to the terminal.

@sariel "It sounds like to me you're frustrated because this is a new platform for you. Hang in there. Yes it's hard, but the benefits are huge."

I have been using docker since 2015, but did not learn all the details. Usually some other guys at works were setting it up and used to tell what commands to run. I see the benefits of it, once it is configured, its very nice that you do not need to install on your machine various stuff by hand. Just run one command you have all programms for the project.
Just setting up if you do not know things is hard. Knowing how to see logs will make it way easier to identify problems. So I learned hard way. Probably one of first things to learn about docker and probably any program is to learn to see logs.

If you tell Compose to move stuff to the background, it will interpret it as if you were launching a production instance and completely detach from the terminal. Returning control but continuing to output into a terminal isn't normal and I for one hate programs that do that by default.