MYSQL , restrict user from hosts, change restriction, restrict users from docker container hosts

 MYSQL Docker container created user root is root@%, so it can connect from any host

During MYSQL init set up , in init.sql, you might have

CREATE USER 'test'@'%' IDENTIFIED BY 'gitea';

GRANT ALL PRIVILEGES ON `gitea`.* TO 'test'@'%';

thats allowing user test to connect from any host, to enforce restriction for the user from a docker container service from any docker container within a docker subnet, its more safer to do :

CREATE USER 'test'@'169.255.255.%' IDENTIFIED BY 'gitea';

GRANT ALL PRIVILEGES ON `gitea`.* TO 'test'@'169.255.255.%';

Or if your init.sql already ran, you can do :

RENAME USER 'test'@'%' TO 'test'@'169.255.255.%';

You can do this with root user as well, 

If root@'localhost' already exists, drop the wide one:

sql

Copy code

DROP USER 'root'@'%';

you can use SQL statement to check:

SELECT user, host, plugin FROM mysql.user WHERE user='root';

Docker Compose MYSQL init, MYSQL port 3306

 docker mysql service has to use port 3306 to start multiple :

version: '3.8'
services:
mysql_db1:
image: mysql:8
environment:
MYSQL_ROOT_PASSWORD: password1
MYSQL_DATABASE: db1
ports:
- "3306:3306" # Maps host port 3306 to container port 3306
volumes:
- db_data1:/var/lib/mysql

mysql_db2:
image: mysql:8
environment:
MYSQL_ROOT_PASSWORD: password2
MYSQL_DATABASE: db2
ports:
- "3307:3306" # Maps host port 3307 to container port 3306
volumes:
- db_data2:/var/lib/mysql

volumes:
db_data1:
db_data2:

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

To add an init.sql script to your MySQL Docker Compose setup to create the gitea and keycloak databases, follow these steps: Create the init.sql file.

Create a file named init.sql (or any other name ending in .sql, .sh, or .sql.gz) in a directory accessible to your docker-compose.yml file. For example, create a subdirectory named mysql-init and place init.sql inside it.

Code

    -- mysql-init/init.sql
    CREATE DATABASE IF NOT EXISTS `gitea`;
    CREATE DATABASE IF NOT EXISTS `keycloak`;

    -- You might also want to create dedicated users and grant privileges here
    -- For example:
    -- CREATE USER 'gitea_user'@'%' IDENTIFIED BY 'gitea_password';
    -- GRANT ALL PRIVILEGES ON `gitea`.* TO 'gitea_user'@'%';
    -- CREATE USER 'keycloak_user'@'%' IDENTIFIED BY 'keycloak_password';
    -- GRANT ALL PRIVILEGES ON `keycloak`.* TO 'keycloak_user'@'%';
    -- FLUSH PRIVILEGES;

Modify your docker-compose.yml.

In your docker-compose.yml file, add a volumes entry to your MySQL service to mount your mysql-init directory into the /docker-entrypoint-initdb.d directory within the MySQL container.

Code

    version: '3.8'

    services:
      mysql:
        image: mysql:8.0 # Or your desired MySQL version
        environment:
          MYSQL_ROOT_PASSWORD: your_root_password
          # Optional: Define default database, user, and password for initial setup
          # MYSQL_DATABASE: default_database
          # MYSQL_USER: default_user
          # MYSQL_PASSWORD: default_password
        volumes:
          - ./mysql-init:/docker-entrypoint-initdb.d
          - mysql_data:/var/lib/mysql # For persistent data
        ports:
          - "3306:3306"
        networks:
          - my_network

      gitea:
        image: gitea/gitea:latest
        environment:
          DB_TYPE: mysql
          DB_HOST: mysql:3306
          DB_NAME: gitea
          DB_USER: gitea_user # If you created a dedicated user
          DB_PASSWD: gitea_password # If you created a dedicated user
          # ... other Gitea configurations
        depends_on:
          - mysql
        networks:
          - my_network

      keycloak:
        image: quay.io/keycloak/keycloak:latest
        environment:
          KC_DB: mysql
          KC_DB_URL: jdbc:mysql://mysql:3306/keycloak
          KC_DB_USERNAME: keycloak_user # If you created a dedicated user
          KC_DB_PASSWORD: keycloak_password # If you created a dedicated user
          # ... other Keycloak configurations
        depends_on:
          - mysql
        networks:
          - my_network

    volumes:
      mysql_data:

    networks:
      my_network:

Run Docker Compose.

Navigate to the directory containing your docker-compose.yml file and run:

Code

    docker-compose up -d

The init.sql script will execute automatically when the MySQL container starts for the first time (when the /var/lib/mysql data directory is empty), creating the gitea and keycloak databases. Subsequent restarts will not re-run the init.sql script unless the mysql_data volume is cleared.

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.

s6 overlay in docker, /init, sevices.d

 S6 overlay changes 1 process 1 container to multiple process 1 container in docker:

set up guide:

https://medium.com/@yashpateld22d/how-to-run-multiple-services-in-docker-using-s6-overlay-wazuh-logging-kubernetes-ready-setup-3a5652b3b698

use case example

/etc/services.d/
├── webapp/
│ └── run
├── redis/
│ └── run
└── cron/
└── run

In Alpine Docker containers using s6-overlay,

scripts within /etc/services.d/<service-name>/run

are executed when the container starts and

the s6-overlay process manager initializes and starts the defined services.

https://github.com/just-containers/s6-overlay?tab=readme-ov-file#usage

S6 initilization requires to have ENTRYPOINT["/init"] in DockerFile

Sets /init as the entrypoint to enable s6 supervision

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