Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Docker Daemon Access#1006

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
ThatAmatoGuy merged 1 commit intomasterfromdocker-daemon-access
Jul 2, 2024
Merged
Show file tree
Hide file tree
Changes fromall commits
Commits
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 10 additions & 20 deletions_docs/kb/articles/docker-daemon-access.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -11,18 +11,21 @@ categories: [Pipelines]
support-reviewed: 2023-04-18 LG
---

This article describes how to access the Docker Daemon within a pipeline step for custom use cases.

## Docker Daemon access support

This article describes how to access the Docker Daemon within a pipeline step for custom use cases.
> 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.

Codefresh's built-in steps cover the most common uses-cases for access to the Docker Daemon:

## Docker Daemon access support
Codefresh's built-in steps cover the most common uses-cases for access to the Docker Daemon:
* Build a Docker image: [Build step]({{site.baseurl}}/docs/pipelines/steps/build/)
* Push a Docker image: [Push step]({{site.baseurl}}/docs/pipelines/steps/push/)
* Run a Docker Composition: [Composition step]({{site.baseurl}}/docs/pipelines/steps/composition/) and [Service Containers]({{site.baseurl}}/docs/pipelines/service-containers/)

You may have custom use-cases when you need direct access to the Docker Daemon in your steps.
For example:

* As part of your test-step you need to dynamically create new containers ([Testcontainers](https://www.testcontainers.org/) library)
* You need to run a composition and dynamically add to that composition a new container you'll create
* You need to send specific flags to your docker-build process
Expand All@@ -32,6 +35,7 @@ For all custom cases, you can access the Docker Daemon in your pipeline step by
## Direct access to Docker Daemon options

There are two main options to access the Docker Daemon in a pipeline step:

* **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.
* **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.

Expand All@@ -51,15 +55,6 @@ docker_daemon_access:
- docker build -t your/image -f yourDockerfile .
```

* Hybrid Runtime Environments (REs)
In Hybrid REs with the Codefresh Runner, this is the default approach to access the Docker Daemon.
Since the REs run in your infrastructure, access to the Docker Daemon in a `freestyle` step is enabled by default.
* SaaS REs
SaaS REs do not support this approach as the Docker Daemon is not exposed to `freestyle` steps by default for security reasons.
You can still use the RE **hosted by Codefresh**. For this option, you'll need a **dedicated Runtime Environment**.



### Accessing the Docker Daemon in a composition step

The following snippet shows an example of how to access the Docker Daemon in a `composition` step:
Expand DownExpand Up@@ -94,11 +89,8 @@ docker_daemon_access:

* On-premises
This approach is supported out-of-the-box in on-premises environments.


* Hybrid REs
Docker socket mapping in `composition` is supported only when the concurrency is set to **all**, or in a **dedicated cluster** provided by Codefresh.

Docker socket mapping in `composition` is supported only when the concurrency is set to **all**.

A similar implementation can be achieved using **[Service Containers]({{site.baseurl}}/docs/pipelines/service-containers/)** :

Expand All@@ -123,15 +115,13 @@ docker_daemon_access_serv_cont:
{% endraw %}

{{site.data.callout.callout_tip}}
We encourage you to keep using our built-in steps as they cover almost all common use cases for access to the Docker Daemon.
We encourage you to keep using our built-in steps as they cover almost all common use cases for access to the Docker Daemon.

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.

Reserve directly accessing the Docker Dameon **for very specific use-cases.**



## Related Items

[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
[Caching in pipelines]({{site.baseurl}}/docs/pipelines/pipeline-caching/)

6 changes: 3 additions & 3 deletions_docs/kb/articles/testcontainers-library-in-pipeline.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -13,6 +13,8 @@ support-reviewed: 2023-04-18 LG

## Overview

> 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.

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/).

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).
Expand All@@ -39,8 +41,6 @@ using_testcontainers:

{% endraw %}

> **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.

### Dealing with Private Docker Images

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.
Expand DownExpand Up@@ -143,7 +143,7 @@ using_testcontainers:

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.

> **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.
> **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.

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.

Expand Down
[8]ページ先頭
©2009-2025 Movatter.jp