You signed in with another tab or window.Reload to refresh your session.You signed out in another tab or window.Reload to refresh your session.You switched accounts on another tab or window.Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: _docs/kb/articles/docker-daemon-access.md
+10-20Lines changed: 10 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,18 +11,21 @@ categories: [Pipelines]
11
11
support-reviewed:2023-04-18 LG
12
12
---
13
13
14
+
This article describes how to access the Docker Daemon within a pipeline step for custom use cases.
14
15
16
+
##Docker Daemon access support
15
17
16
-
This article describes how to access the Docker Daemon within a pipeline step for custom use cases.
18
+
>Docker Daemon as only available on the**Hybrid Runtime** and**On-Prem** instances. Docker Daemon access is not supported on**SaaS Runtimes** for security Reasons.
19
+
20
+
Codefresh's built-in steps cover the most common uses-cases for access to the Docker Daemon:
17
21
18
-
##Docker Daemon access support
19
-
Codefresh's built-in steps cover the most common uses-cases for access to the Docker Daemon:
20
22
* Build a Docker image:[Build step]({{site.baseurl}}/docs/pipelines/steps/build/)
21
23
* Push a Docker image:[Push step]({{site.baseurl}}/docs/pipelines/steps/push/)
22
24
* Run a Docker Composition:[Composition step]({{site.baseurl}}/docs/pipelines/steps/composition/) and[Service Containers]({{site.baseurl}}/docs/pipelines/service-containers/)
23
25
24
26
You may have custom use-cases when you need direct access to the Docker Daemon in your steps.
25
27
For example:
28
+
26
29
* As part of your test-step you need to dynamically create new containers ([Testcontainers](https://www.testcontainers.org/) library)
27
30
* You need to run a composition and dynamically add to that composition a new container you'll create
28
31
* You need to send specific flags to your docker-build process
@@ -32,6 +35,7 @@ For all custom cases, you can access the Docker Daemon in your pipeline step by
32
35
##Direct access to Docker Daemon options
33
36
34
37
There are two main options to access the Docker Daemon in a pipeline step:
38
+
35
39
***In a[`freestyle`]({{site.baseurl}}/docs/pipelines/steps/freestyle/) step**: By using an image with Docker installed, and mounting the required volumes (the Docker socket). In Hybrid Runtime Environments, these volumes are already mounted. You don't need to specify anything else.
36
40
***In a[`composition`]({{site.baseurl}}/docs/pipelines/steps/composition/) step**: Similar to the`freestyle` step option, you'll need to use an image with Docker installed in one of the composition-services. And mount the corresponding volumes to that composition-service.
37
41
@@ -51,15 +55,6 @@ docker_daemon_access:
51
55
-docker build -t your/image -f yourDockerfile .
52
56
```
53
57
54
-
* Hybrid Runtime Environments (REs)
55
-
In Hybrid REs with the Codefresh Runner, this is the default approach to access the Docker Daemon.
56
-
Since the REs run in your infrastructure, access to the Docker Daemon in a`freestyle` step is enabled by default.
57
-
* SaaS REs
58
-
SaaS REs do not support this approach as the Docker Daemon is not exposed to `freestyle` steps by default for security reasons.
59
-
You can still use the RE **hosted by Codefresh**. For this option, you'll need a **dedicated Runtime Environment**.
60
-
61
-
62
-
63
58
### Accessing the Docker Daemon in a composition step
64
59
65
60
The following snippet shows an example of how to access the Docker Daemon in a`composition` step:
@@ -94,11 +89,8 @@ docker_daemon_access:
94
89
95
90
* On-premises
96
91
This approach is supported out-of-the-box in on-premises environments.
97
-
98
-
99
92
* Hybrid REs
100
-
Docker socket mapping in `composition` is supported only when the concurrency is set to **all**, or in a **dedicated cluster** provided by Codefresh.
101
-
93
+
Docker socket mapping in `composition` is supported only when the concurrency is set to **all**.
102
94
103
95
A similar implementation can be achieved using **[Service Containers]({{site.baseurl}}/docs/pipelines/service-containers/)**:
We encourage you to keep using our built-in steps as they cover almost all common use cases for access to the Docker Daemon.
118
+
We encourage you to keep using our built-in steps as they cover almost all common use cases for access to the Docker Daemon.
127
119
128
120
Because the built-in steps support different levels of optimization, such as the Codefresh caching mechanism, their usage is directly related to the level of traceability. For example, the images you build in Codefresh using the `build` step are reflected in the images view and other dashboards we provide.
129
121
130
122
Reserve directly accessing the Docker Dameon **for very specific use-cases.**
131
123
132
-
133
-
134
124
## Related Items
125
+
135
126
[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
136
127
[Caching in pipelines]({{site.baseurl}}/docs/pipelines/pipeline-caching/)
Copy file name to clipboardExpand all lines: _docs/kb/articles/testcontainers-library-in-pipeline.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,6 +13,8 @@ support-reviewed: 2023-04-18 LG
13
13
14
14
##Overview
15
15
16
+
>Docker Daemon as only available on the**Hybrid Runtime** and**On-Prem** instances. Docker Daemon access is not supported on**SaaS Runtimes** for security Reasons.
17
+
16
18
Testcontainers is a library, for Java, that allows you to run your tests interacting with Docker containers, by using the`docker-java` client library. More information on its official site:[testcontainers.org](https://www.testcontainers.org/).
17
19
18
20
Besides the ability to run a Gradle/Maven process in your pipeline, to effectively use Testcontainers in Codefresh, you'll need to provide direct access to the Docker Daemon, so it can perform its internal operations (creating the containers, getting network information from them, executing commands in the running containers, among other common actions).
@@ -39,8 +41,6 @@ using_testcontainers:
39
41
40
42
{% endraw %}
41
43
42
-
> **Note** : the step above is being executed on a Hybrid RE (Runner RE), where access to the Docker Daemon is enabled by default. If you're using a SaaS RE (hosted by Codefresh), you can use a`composition` step. Look for the article mentioned above for more details on how to access the Docker Daemon in Codefresh.
43
-
44
44
### Dealing with Private Docker Images
45
45
46
46
When you use freestyle steps, or compositions, Codefresh automatically deals with the operations required to pull the private image(s), from the corresponding registry, referenced in the`image` field of the freestyle step, or in the composition-services.
@@ -143,7 +143,7 @@ using_testcontainers:
143
143
144
144
Take into consideration that Service Containers also supports a reference to a `docker-compose.yml` file. If you can dynamically modify that file, adding the private images you'll need, then, in the `services.composition` field, you can just reference that `docker-compose.yml` file. That way you don't need to hardcode each of the images in the composition, for that step.
145
145
146
-
> **Note** : this way of pre-pulling images using service-containers is only valid when using Hybrid REs, since the main step will automatically have access to the Docker Daemon. If you're running in a SaaS RE, then, you can use one of the other alternatives to access the Docker Daemon. For example, using a `composition` step you can define each of the composition-services to be an image to be pulled, and the `composition_candidates` could be the service that will run the Testcontainers tests, and the one with access to the Docker Daemon.
146
+
> **Note** : this way of pre-pulling images using service-containers is only valid when using Hybrid REs, since the main step will automatically have access to the Docker Daemon.
147
147
148
148
The benefit of this approach (" _pre-pulling the images_ "), over Option 1, is that you don't need to worry about authentication to the registry, Codefresh will automatically handle that, based on the registry integrations you have already added to Codefresh.