docker expose, docker-compose expose

 

1. Dockerfile → EXPOSE

• Purely documentation/metadata.

• Doesn’t actually open or bind anything.

• Other containers on the same network can still reach your app via container_name:port even if you don’t EXPOSE it.

• Example: you can still curl http://web:8080 inside another container, even if the Dockerfile doesn’t have EXPOSE 8080.

---

2. docker-compose.yml → expose:

• Same as Dockerfile’s EXPOSE, but defined in Compose instead.

• Makes the port visible to other containers in the same Compose network.

• Does not publish it to your host machine.

---

3. docker-compose.yml → ports:

• This is the one that really matters if you want to access the container from outside Docker (e.g., browser, Postman, curl from host).

• Maps container port → host port.
  Example:

  ports:
    - "8080:80"   # host:container

DockerFile / docker compose CMD, entry point, docker run, docker compose exec, run

https://devtron.ai/blog/cmd-and-entrypoint-differences/ 

CMD & ENTRYPOINT means same thing for DockerFile && DockerCompose.yml

except DockerCompose.yml overwrites CMD and ENTRYPOINT if already defined in DockerFile

• ENTRYPOINT (Dockerfile) / entrypoint (Docker Compose):

  • Defines the primary executable or script that will always be run when the container starts.
  • It's the "fixed" part of the command.
  • Arguments provided by CMD (or the command in Docker Compose) are appended to the ENTRYPOINT command.
  • Less easily overridden at runtime; requires the --entrypoint flag with docker run.

  • CMD (Dockerfile) / command (Docker Compose):

    • Provides default arguments or a default command that can be easily overridden when the container is run.
    • If an ENTRYPOINT is defined, CMD provides arguments to that ENTRYPOINT.
    • If no ENTRYPOINT is defined, CMD defines the entire command to be executed.
    • Easily overridden by providing arguments directly to docker run or by defining a command in Docker Compose.

    Consider a Dockerfile with:

    Code

    
    

    ENTRYPOINT ["nginx"]

    CMD ["-g", "daemon off;"]

    When this container runs, nginx -g "daemon off;" will be executed. If you run docker run myimage bash, bash will be treated as an argument to nginx, resulting in nginx bash, which is likely not what you want.

    Now, consider a Dockerfile with:

    Code

    
    

    CMD ["nginx", "-g", "daemon off;"]

    When this container runs, nginx -g "daemon off;" will be executed. If you run docker run myimage bash, bash will override the CMD, and only bash will be executed.

  ----------------------------------------------------------------------------------------------

docker run:

Purpose:

Creates and starts a new container from a specified Docker image.

Behavior:

When you use docker run, you are launching a fresh instance of a container, complete with its own isolated filesystem, network configuration, and process space.

Use Case:

Ideal for initiating new services, testing images, or running one-off commands in a fresh environment.

docker compose exec:

Purpose:

Executes a command inside an already running container that is part of a Docker Compose service.

Behavior:

It allows you to interact with a container that is actively running within your Docker Compose application, without creating a new container. The command runs within the existing container's environment and filesystem.

docker compose exec [SERVICE] /bin/bash command is used to execute the /bin/bash command within a running container that is part of a Docker Compose service.

Explanation:

docker compose exec:

This is the command used to execute a command within a running container managed by Docker Compose.

[SERVICE]:

This placeholder represents the name of the service defined in your docker-compose.yml file (e.g., web, db, app). You need to replace this with the actual name of the service you want to interact with.

/bin/bash:

This is the command being executed inside the container. It launches a Bash shell, providing you with an interactive command-line interface within that specific container.

If you need to access a running Docker container managed by Docker Compose and it does not have /bin/bash installed, you can try the following methods:

Use /bin/sh or /bin/ash: Many lightweight Docker images (like Alpine Linux-based images) do not include bash but provide sh (Bourne Shell) or ash (Almquist Shell). You can attempt to access the container using these shells:

Code

    docker compose exec <service_name> sh

docker compose run:

This command is used within a Docker Compose project, defined by a docker-compose.yaml file.

It runs a one-time command against a specific service defined in the docker-compose.yaml file.

It leverages the configuration (volumes, networks, etc.) defined for that service in the YAML file, but the command passed with run overrides the default command defined in the service.

Crucially, docker compose run does not create or map the service's ports by default, preventing port collisions if other services are already running. The --service-ports flag or manual port mapping with -p is required to expose ports.

docker compose run does create a new container for the execution of the specified one-time command. By default, this container persists after the command finishes. However, the --rm flag can be used to automatically remove the container once the command exits. This is a common practice for transient tasks like running migrations or tests.

Both docker compose run, docker compose exec respects ENTRYPOINT defined etiher in yml or in dockerFile:

https://stackoverflow.com/questions/76260433/does-docker-compose-exec-service-command-ignore-the-entrypoint

docker compose exec does not use defined ENTRYPOINT from the Dockerfile of the service's image by default.

    It allows you to run a command in an already running container. It would make no sense to execute the entrypoint as part of that, as it might run a long running process or similar, and never return, or exit, an then never actually run the command you wanted to. Hope that makes sense.

docker compose run uses the defined ENTRYPOINT from the Dockerfile of the service's image by default.

When you use docker compose run <service_name> [command], the ENTRYPOINT defined in the Dockerfile for the specified service_name will be executed. Any command you provide after the service name will then be appended as arguments to that ENTRYPOINT.

You can also override the ENTRYPOINT for a specific docker compose run command by using the --entrypoint flag, for example:

Code

docker compose run --entrypoint=/bin/bash my_service

This would start a bash shell within the my_service container, ignoring its default ENTRYPOINT.

Docker Compose will auto load .env variable

 Docker Compose retrieves environment variables from a .env file located in the same directory as your docker-compose.yml file. This is the default and most common method.

How it works:

Placement:

Create a file named .env in the root directory of your Docker Compose project, alongside your docker-compose.yml file.

Content:

Define your environment variables within this .env file using a simple key-value pair format, one variable per line:

Code

    VARIABLE_NAME=variable_value

    ANOTHER_VAR=another_value

Referencing in docker-compose.yml: In your docker-compose.yml file, you can then reference these variables using the ${VARIABLE_NAME} syntax for interpolation:

Code

    version: '3.8'

    services:

      web:

        image: "my-app:${APP_VERSION}"

        environment:

          - DB_HOST=${DATABASE_HOST}

Automatic Loading: When you run docker compose up (or docker-compose up with older versions), Docker Compose automatically detects and loads the variables from the .env file, substituting them into your docker-compose.yml configuration before creating and starting the services.

Additoinal Docker Useful Info - bip, subnet, daemon

/etc/docker/dameon.json

https://docs.docker.com/engine/network/drivers/bridge/#:~:text=In%20terms%20of%20networking%2C%20a,user%2Ddefined%20custom%20bridge%20networks.

https://serverfault.com/questions/916941/configuring-docker-to-not-use-the-172-17-0-0-range#:~:text=The%20default%20bridge,networks%20in%20the%20wrong%20range.

 In Docker, bip in daemon.json refers to the "Bridge IP" address. It specifies the IP address and subnet used by the Docker daemon's default bridge network, which is used for communication between the host and containers

by default, Docker uses a bridge network. When you start Docker, a default bridge network is automatically created, and new containers will connect to it unless you specify otherwise. This network, also known as the `docker0 bridge, provides basic networking functionality for containers. 

In Docker's daemon.json, both "bip" and "default-address-pools" are used to configure networking, but they serve different purposes. "bip" defines the IP address and subnet of the default bridge network, while "default-address-pools" specifies a pool of subnets for Docker to use when creating user-defined bridge networks. 

docker-compose.yml

https://docs.docker.com/engine/daemon/ipv6/#:~:text=2%20Accept:%20*/*-,Dynamic%20IPv6%20subnet%20allocation,IPv6%20pools%20of%20your%20own

The networks key in a docker-compose.yml file is used to define and assign custom networks to your Docker services. This allows you to manage and isolate communication between containers more effectively. 

https://mrkaran.dev/tils/docker-custom-subnet/

While Docker Compose allows defining subnets for networks within a Compose file, using default-address-pools in daemon.json provides a global configuration for Docker itself, impacting all networks, including those created by Compose when a subnet isn't explicitly defined. This ensures consistent subnet usage across all Docker environments, including those managed by Compose. 

https://serverfault.com/questions/916941/configuring-docker-to-not-use-the-172-17-0-0-range

docker-compose network subnets can be outside the default address pool defined in daemon.json. Docker Compose allows you to specify a subnet for a network, and if that subnet is not within the address pools defined in daemon.json, it will still function, but it will be a custom network. 

If you define network and dont define a network in service, it will use a random IP inthe subnet, 

you can also define a specific network with IP in each service

Docker compose container knowledge 101

 what requirements.txt Does

requirements.txt is a plain text file that lists all the Python packages your project depends on.

When you run:

bash

Copy

Edit

pip install -r requirements.txt

---------------------------------------------------------------------------------

docker-compose up -d starts the crawler container in the background (idling with tail -f /dev/null).

When you run:

docker-compose run --rm crawler python crawler.py

it spins up a second, temporary container with the same image and runs the script — and then removes it afterward (--rm).

So yes, you'll briefly have two containers:

One idle (crawler)

One executing your script (docker-compose run instance)

---------------------------------------------------------------

command: tail -f /dev/null  # Keeps container idle in docker-compose.yml file what does it do ?

is a common Docker trick that means:

"Keep the container running, but do nothing useful."

---

🧠 Why would you do this?

Because by default, Docker containers exit immediately after their main process finishes.
So if your service doesn't do anything (e.g., no long-running server or script), it will just shut down.

By running:

tail -f /dev/null

You:

• Start a "fake" long-running process (like watching an empty file forever)

• Prevent the container from exiting

• Allow yourself to exec into the container or manually run things later

BashProfile Export Variable and Python WSGI docker issue

 https://stackoverflow.com/questions/51789509/bash-profile-variables

.bash_profile exported variable

can be shown by echo $MYVAR

if you have

export MYVAR=xxxx

in bash_profile

however, it only works in interactive shell, so broken pipe, new shell, need to call source .bash_profile again

you can verify that before source echo $MYVAR is empty and after source .bash_profile they have value.

Then if your docker-compose.yml django app:

  app:

                                user: "${uID}:${gID}"

they will fail on new shell cause uID and gID is empty

MYSQL docker user permission & MYSQL need 3306

 For example, if you set:

MYSQL_DATABASE=mydb

MYSQL_USER=myuser

MYSQL_PASSWORD=mypassword

The myuser will have full privileges (such as SELECT, INSERT, UPDATE, DELETE, etc.) on mydb but will not have privileges on other databases unless explicitly granted later.

MYSQL need port 3306, you can map different port from 0.0.0.0 to 3306

You will need a ini file to grant global permission to docker mysql user if you want to 

GRANT ALL PRIVILEGES ON *.* TO 'myuser'@'%'; FLUSH PRIVILEGES;

Dockerfile run apk add --virtual, build base, pip install

 https://stackoverflow.com/questions/46221063/what-is-build-deps-for-apk-add-virtual-command

apk installs global stuff into the container like python, dependecy packages,

pip install python sepcific libraries specified in requirement file

https://stackoverflow.com/questions/46221063/what-is-build-deps-for-apk-add-virtual-command

What is .build-deps for apk add --virtual command?

RUN apk add --no-cache --virtual .build-deps \
gcc \
freetype-dev \
musl-dev

RUN pip install --no-cache-dir <packages_that_require_gcc...> \

RUN apk del .build-deps

-t, --virtual NAME    Instead of adding all the packages to 'world', create a new 
                      virtual package with the listed dependencies and add that 
                      to 'world'; the actions of the command are easily reverted 
                      by deleting the virtual package

https://forums.docker.com/t/what-does-run-apk-add-do/128234

apk is Alpine Linux package system, so what it does is that it installs python, g++ and make

https://hub.docker.com/r/alpinelinux/build-base

Build base
This is a docker image that can be used to build Alpine Linux packages with abuild


DockerFile
From python:3.10-alpine3.14

RUN apk update
# gcc pytho3-dev musl-dev is for mysql client depedencies
RUN apk add --virtual build-deps gcc python3-dev musl-dev
RUN apk add --no-cache mariadb-dev

# For xmlsec required for  python3-saml
# https://pypi.org/project/xmlsec/
RUN apk add build-base libressl libffi-dev libressl-dev libxslt-dev libxml2-dev xmlsec-dev xmlsec

ENV PYTHONBUFFERED 1

COPY ./requirements.txt /requirements.txt

RUN pip install -r /requirements.txt

#
RUN apk add expat-dev
RUN pip install mod_wsgi-standalone

RUN apk del build-deps

RUN mkdir /app
WORKDIR /app
COPY ./app /app


requirements.txt
Django>=4.0.4,<4.1.0
djangorestframework>=3.13.1,<3.20.0

mysqlclient>=2.1.0,<2.2.0

flake8>=4.0.1,<4.1.0

lxml==4.9.3
xmlsec==1.3.13
python3-saml==1.11.0

requests>=2.28.1,<2.29.0

django-cors-headers >=3.13.0,<3.14.0

django-smtp-ssl>=1.0,<2.0