max-voitcov
3ddce62647
A `dokploy_mount` with `type = "volume"` and no `volume_name` was accepted
by both this provider and Dokploy. Dokploy renders the mount as
`{Source: volumeName || "", Target: mountPath}`, and Docker reads an empty
source as an anonymous volume: every deploy created a fresh one and orphaned
the last, so the data never survived a redeploy while disk usage climbed.
Nothing errored at any point, which is what made it worth catching here.
The pairing is now checked at plan time, before anything is created, and the
error explains the consequence rather than only the rule. The same validator
covers `bind` without `host_path` and `file` without `file_path`, and rejects
a field set against the wrong type, which Dokploy would otherwise ignore.
Verified against a live v0.30.2 instance: the offending config plans cleanly
before the change and is refused after it.
43 lines
2.1 KiB
Markdown
43 lines
2.1 KiB
Markdown
---
|
|
# generated by https://github.com/hashicorp/terraform-plugin-docs
|
|
page_title: "dokploy_mount Resource - dokploy"
|
|
subcategory: ""
|
|
description: |-
|
|
A volume, bind mount, or config file attached to a Dokploy service.
|
|
type = "volume" — a named Docker volume; set volume_name.type = "bind" — a path on the host; set host_path.type = "file" — a file rendered from content; set file_path.
|
|
~> A volume mount must set volume_name. Dokploy hands an unset name to Docker as an empty source, which creates a fresh anonymous volume on every deploy and orphans the previous one — the data never survives a redeploy. The provider rejects that combination at plan time.
|
|
---
|
|
|
|
# dokploy_mount (Resource)
|
|
|
|
A volume, bind mount, or config file attached to a Dokploy service.
|
|
|
|
* `type = "volume"` — a named Docker volume; set `volume_name`.
|
|
* `type = "bind"` — a path on the host; set `host_path`.
|
|
* `type = "file"` — a file rendered from `content`; set `file_path`.
|
|
|
|
~> **A `volume` mount must set `volume_name`.** Dokploy hands an unset name to Docker as an empty source, which creates a fresh anonymous volume on every deploy and orphans the previous one — the data never survives a redeploy. The provider rejects that combination at plan time.
|
|
|
|
|
|
|
|
<!-- schema generated by tfplugindocs -->
|
|
## Schema
|
|
|
|
### Required
|
|
|
|
- `mount_path` (String) Path inside the container where the mount appears.
|
|
- `service_id` (String) ID of the service this mount attaches to. Must match `service_type` — an application ID, a compose ID, a postgres ID, and so on.
|
|
- `service_type` (String) The kind of service this mount attaches to. Valid values: `application`, `postgres`, `mysql`, `mariadb`, `mongo`, `redis`, `compose`, `libsql`.
|
|
- `type` (String) The kind of mount to create. Valid values: `bind`, `volume`, `file`.
|
|
|
|
### Optional
|
|
|
|
- `content` (String) Contents of the generated file, when `type` is `file`.
|
|
- `file_path` (String) Path of the generated file, when `type` is `file`.
|
|
- `host_path` (String) Path on the host, when `type` is `bind`.
|
|
- `volume_name` (String) Name of the Docker volume, when `type` is `volume`.
|
|
|
|
### Read-Only
|
|
|
|
- `id` (String) Unique mount identifier.
|