Implement coolify_service resource

[megheaiulian]

Implement initial version of coolify_service resource.

See #51

Related coolify issues:
#5341
#5344

[megheaiulian]

@SierraJC Can you please have a look if the code goes in the right direction ?

Either way I am a bit stuck at the moment because the Coolify API has a issue where it does not return the application by uuid after creation. coollabsio/coolify#5330
Have you perhaps had any similar issues returning applications from API (e.g.: when implementing data source for applications)?

[SierraJC]

The Coolify API has a lot of bugs unfortunately. I've submitted a few PRs to fix issues, and is why the OpenAPI overlay tool is being used in this project to fix the schema where possible.
Looking at the dockercompose API code @ https://github.com/coollabsio/coolify/blob/f28eefe603fab5becabd8821746304fa622b5802/app/Http/Controllers/Api/ApplicationsController.php#L1238-L1314
The code is trying to create a Service instead of Application. This is most likely causing the unexpected behaviour.

I'll give the code a more thorough review in the next day or two - had a quick look and it looks pretty good so far! 👍

[megheaiulian]

@SierraJC Thank you for your review.
The thing is that it does create the application, returns a uuid and I can access the create application in the UI.
When it then tries to get that application it fails at https://github.com/coollabsio/coolify/blob/f28eefe603fab5becabd8821746304fa622b5802/app/Http/Controllers/Api/ApplicationsController.php#L1380.
Also querying all applications returns nothing.

I suspect that there is something wrong with the way teams are linked. Perhaps here: https://github.com/coollabsio/coolify/blob/676f616efa668e92e3adda7c87cdea685f1000a5/app/Models/Application.php#L185

[SierraJC]

I think you're right, the Application.ownedByCurrentTeamAPI function called is specific to the other application types, while the dockercompose application is actually a service, so should be using a different function (possibly ApplicationService.ownedByCurrentTeamAPI).

The created dockercompose "application" appears in the get/list /services API, even when created outside of the API by the UI. So it is probably intended behaviour by Coolify.
We could probably adapt and use the /services endpoint for read/update/delete events, just for dockercompose?

[megheaiulian]

Pfff what a mess :).
In this case I think we need to name this Terraform resource coolify_service.
We can create the service via /applications/dockercompose and retrieve it via /services/:id.
Updating services via the API is not yet support but I think at first we can delete and recreate the service via de API.

In the future we can support one click services in another way, although right now users will be able to just dump the docker compose in the docker_compose_raw field.

[SierraJC]

Agreed, this should be represented as a coolify_dockerfile_service

Updating services via the API is not yet support but I think at first we can delete and recreate the service via de API.

FYI, to do this you can add a RequiresReplace() PlanModifier on each attribute, or implement the resource.ResourceWithModifyPlan interface (set resp.RequiresReplace value).
I believe the destroy operation via API is an asynchronous operation. Some kind of polling may be required, to ensure destroyed resources are fully deleted on Coolify's end before recreating...

Once the service is created, the images in the dockerfile are each created as a ServiceApplication / ServiceDatabase which is not currently supported by the API. How will this impact your use case?

[megheaiulian]

@SierraJC I've added support for creating and updating services in coolify in coollabsio/coolify#5344.
I think that the changes will be available in the next release of coolify.
I've updated the provider to support creating, updating and deleting services and linked to updated openapi def.
Can you please have another look at the code 🙏 ?

[SierraJC]

When trying to create the resource, the beta.399 API is returning 500.

Have you tested the provider locally?
If not, you can run make install and then add a dev_override to ~/.terraformrc [docs] ie "registry.terraform.io/sierrajc/coolify" = "${GOPATH}/bin". You can then use your modified provider binary as normal, in regular terraform files.
Can get two birds with one stone by doing this in the examples/resources/<resource name> folder.

Move the PR out of draft, and re-request review when you'd like me to check it again. Excellent effort so far, looks good 👍

[megheaiulian]

Thank you for the review. I'll have a look and update this.
There have been some adjustments to the changes I did in Coolify and they now require another round of adjustments including updating OpenApi types.

[megheaiulian]

Updated this PR and opened another one on Coolify to fix these little problems with the api: coollabsio/coolify#5448

[megheaiulian]

@SierraJC Coolify has been updated with the necessary fixes and I have also update the defs here.
Please have another look 🙏

[SierraJC]

I'm unable to get it working, crashes immediately on create API call with beta.406

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x8fcbb6]

goroutine 199 [running]:
terraform-provider-coolify/internal/service/service.(*ServiceResource).Create(0xc0004765b8, {0x1427568, 0xc0001249f0}, {{{{0x142e9a0, 0xc0001257d0}, {0x10d5f00, 0xc000125560}}, {0x14312b0, 0xc000714230}}, {{{0x142e9a0, ...}, ...}, ...}, ...}, ...)
	/home/dev/projects/coolify-provider/internal/service/service/resource_service.go:77

https://github.com/plumelo/terraform-provider-coolify/blob/81e48aa19cd860d4a1c3ee60f6b8f6bc1c153b74/internal/service/service/resource_service.go#L77

*res.JSON201.Uuid is nil. The API request returned 201 created but has an error body. The API obviously should not return status 2** on errors 🤯

{"message":"Validation failed.","errors":{"destination_uuid":["The destination uuid field must be a string."]}}

Manually providing a destination_uuid results in API returning error 500 {"message": "Server Error"} same as my last comment.

---

Please test the provider on your end so these issues can be spotted sooner

Have you tested the provider locally? If not, you can run make install and then add a dev_override to ~/.terraformrc [docs] ie "registry.terraform.io/sierrajc/coolify" = "${GOPATH}/bin". You can then use your modified provider binary as normal, in regular terraform files. Can get two birds with one stone by doing this in the examples/resources/<resource name> folder.

[megheaiulian]

@SierraJC I have just test this locally with the latest beta.406 version of Coolify and everything worked for me.
I have used the local development environment for Coolify and built the provider locally and used it in separate test Terraform setup from the start.
I am testing with this same resource:

resource "coolify_service" "beszel" {
  name        = "beszel"
  description = "Managed by Terraform"

  server_uuid      = "skc8k0gc88s0soskkgwc8088"
  destination_uuid = "xgc4ogo4kcg4wgkwkw84800k"
  project_uuid     = "pwg00gcwsssosocgc0ogcgcc"
  environment_name = "production"

  instant_deploy = true
  compose        = <<EOF
services:
  beszel:
    image: henrygd/beszel:latest
    environment:
      - SERVICE_FQDN_BESZEL_8090
    volumes:
      - beszel_data:/beszel_data

  beszel-agent:
    image: henrygd/beszel-agent
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      - PORT=45876
      - KEY=$${KEY}
EOF

}

I tried now to remove destination_uuid and I could replicate the problem. Need to ommit destination_uuid and enviroment_uuid when null.

[megheaiulian]

@SierraJC The Coolify api is not setting the correct status codes. I'll update it and fix that.
Fix in coollabsio/coolify#5448

Fix in coollabsio/coolify#5564