Merge pull request #2088 from grouville/guides

New content to guide docs
This commit is contained in:
Gerhard Lazu 2022-04-08 12:26:59 +01:00 committed by GitHub
commit e8393394a4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 113 additions and 1 deletions

View File

@ -20,6 +20,24 @@ To use a buildkit daemon running in a container named "super-buildkit" on the lo
export BUILDKIT_HOST=docker-container://super-buildkit
```
## Using a custom remote buildkit running in Docker
Dagger can also be configured to use a remote buildkit daemon running in a Docker container. This an be done using the environment variable `DOCKER_HOST`.
```shell
export DOCKER_HOST=ssh://user@IP
```
You will also need to set the `BUILDKIT_HOST` environment variable explained above.
## Running a custom buildkit container in Docker
To run a customized Buildkit version with Docker, this can be done using the below command:
```shell
docker run -d --name dagger-buildkitd --privileged --network=host docker.io/moby/buildkit:latest
```
## OpenTracing Support
Both Dagger and buildkit support opentracing. To capture traces to

View File

@ -0,0 +1,19 @@
---
slug: /1224/self-signed-certificates/
---
# Running Dagger with self-signed certificates
The connection to a container registry or to a remote docker daemon might require the need to add self-signed CA: `x509: certificate signed by unknown authority`.
These operations are being run inside the buildkitd context and require you to mount your certificates inside your buildkit instance.
## Running a custom buildkit in Docker
To run a customized Buildkit version with Docker, this can be done using the below command. You can add as many certificate as you need:
```shell
docker run --net=host -d --restart always -v $PWD/my-cert.pem:/etc/ssl/certs/my-cert.pem --name dagger-buildkitd --privileged moby/buildkit:latest
```
To connect your Dagger client to this custom instance, [please follow these steps](../guides/1223-custom-buildkit.md)

View File

@ -0,0 +1,67 @@
---
slug: /1225/pushing-plan-dependencies/
---
# Pushing your plan's dependencies
After completing your plan and setting up your GHA or Gitlab CI, you'll realize that a lot of `Cue` files are present in the `cue.mod/pkg` directory. These are the dependencies required by Dagger to run your actions :
```shell
cue.mod/
├── pkg
│ ├── dagger.io
│ │ ├── cue.mod
│ │ └── dagger
│ │ └── core
│ └── universe.dagger.io
│ ├── alpine
│ │ └── test
│ ├── aws
│ │ ├── cli
│ │ │ └── test
│ │ └── test
│ ├── bash
│ │ └── test
│ │ └── data
│ ├── cue.mod
│ ├── docker
│ │ ├── cli
│ │ │ └── test
│ │ └── test
│ ├── examples
│ │ ├── changelog.com
│ │ │ ├── elixir
│ │ │ │ └── mix
│ │ │ └── gerhard
│ │ ├── helloworld
│ │ └── todoapp
│ │ ├── public
│ │ └── src
│ │ └── components
│ ├── git
│ ├── go
│ │ └── test
│ ├── netlify
│ │ └── test
│ │ └── testutils
│ ├── nginx
│ ├── powershell
│ │ └── test
│ │ └── data
│ ├── python
│ ├── x
│ │ └── david@rawkode.dev
│ │ └── pulumi
│ └── yarn
│ └── test
│ └── data
│ ├── bar
│ └── foo
└── usr
```
The current best practice is to push your project with these files: it will ensure its consistency between runs.
:::info
We are aware of that and, soon, `dagger project update` will only download the dependencies required by your actions
:::

View File

@ -107,7 +107,15 @@ module.exports = {
label: "Guides",
collapsible: false,
collapsed: false,
items: ["guides/container-images", "guides/cli-telemetry", "guides/docker-cli-load", "guides/docker-cli-run"],
items: [
"guides/container-images",
"guides/cli-telemetry",
"guides/docker-cli-load",
"guides/docker-cli-run",
"guides/custom-buildkit",
"guides/self-signed-certificates",
"guides/pushing-plan-dependencies",
],
},
{
type: "category",