sillyguodong 35596a182b Add configuration item of container.network (#184) ... Close https://gitea.com/gitea/act_runner/issues/177 Related https://gitea.com/gitea/act/pulls/56 ### ⚠️ Breaking The `container.network_mode` is a deprecated configuration item. It may be removed after Gitea 1.20 released. Previously, if the value of `container.network_mode` is `bridge`, it means that `act_runner` will create a new network for job.But `bridge` is easily confused with the bridge network created by Docker by default. We recommand that using `container.network` to specify the network to which containers created by `act_runner` connect. ### 🆕 container.network The configuration file of `act_runner` add a new item of `contianer.network`. In `config.example.yaml`: ```yaml container: # Specifies the network to which the container will connect. # Could be host, bridge or the name of a custom network. # If it's empty, act_runner will create a network automatically. network: "" ``` As the comment in the example above says, the purpose of the `container.network` is specifying the network to which containers created by `act_runner` will connect. `container.network` accepts the following valid values: - `host`: All of containers (including job containers and service contianers) created by `act_runner` will be connected to the network named `host` which is created automatically by Docker. Containers will share the host’s network stack and all interfaces from the host will be available to these containers. - `bridge`: It is similar to `host`. All of containers created by `act_runner` will be connected to the network named `bridge` which is created automatically by Docker. All containers connected to the `bridge` (Perhaps there are containers that are not created by `act_runner`) are allowed to communicate with each other, while providing isolation from containers which are not connected to that `bridge` network. - `<custom_network>`: Please make sure that the `<custom_network>` network already exists firstly (`act_runner` does not detect whether the specified network exists currently. If not exists yet, will return error in the stage of `docker create`). All of containers created by `act_runner` will be connected to `<custom_network>`. After the job is executed, containers are removed and automatically disconnected from the `<custom_network>`. - empty: `act_runner` will create a new network for each job container and their service containers (if defined in workflow). So each job container and their service containers share a network environment, but are isolated from others container and the Docker host. Of course, these networks created by `act_runner` will be removed at last. ### Others - If you do not have special needs, we highly recommend that setting `container.network` to empty string (and do not use `container.network_mode` any more). Because the containers created by `act_runner` will connect to the networks that are created by itself. This point will provide better isolation. - If you set `contianer.network` to empty string or `<custom_network>`, we can be access to service containers by `<service-id>:<port>` in the steps of job. Because we added an alias to the service container when connecting to the network. Co-authored-by: Jason Song <i@wolfogre.com> Reviewed-on: https://gitea.com/gitea/act_runner/pulls/184 Reviewed-by: Jason Song <i@wolfogre.com> Co-authored-by: sillyguodong <gedong_1994@163.com> Co-committed-by: sillyguodong <gedong_1994@163.com>		2023-05-16 14:46:59 +08:00
..
client	Skip counting log length when parseLogRow return nil (#176)	2023-05-06 17:00:52 +08:00
config	Add configuration item of container.network (#184)	2023-05-16 14:46:59 +08:00
envcheck	Refactor to new framework (#98)	2023-04-04 21:32:04 +08:00
labels	Refactor to new framework (#98)	2023-04-04 21:32:04 +08:00
report	Skip counting log length when parseLogRow return nil (#176)	2023-05-06 17:00:52 +08:00
ver	Refactor to new framework (#98)	2023-04-04 21:32:04 +08:00