Portainer.io
Replies: 19 comments 1 reply
-
|
That was actually done by design. |
Beta Was this translation helpful? Give feedback.
-
|
@huib-portainer That makes sense, but my issue with this is that a Git repo is not necessarily static. Moving the compose files or renaming the files breaks this implementation, and I find myself doing that much in the early stages of projects. This causes the deployment configurations to point to invalid filenames or non-existing files. When this happens, it is quite inconvenient that there is this restriction. |
Beta Was this translation helpful? Give feedback.
-
|
if this is a design choice, maybe that could become a default setting and the other option (editable git paths) could be enable by administrators, being aware of the consequences. |
Beta Was this translation helpful? Give feedback.
-
|
Whilst it may be a design choice - if this it what I'm suffering then it's wholly inconvenient... With a load of stacks created from docker-compose.yamls in a git repo, I've now reorganised the git repo and relocated some of the compose files. But I can't update these links in Portainer, and worse, I can't even delete the stack to manually create it as it throws up a FileNotFound errorno2 trying to get the compose file to dcdn the stack... So now I must put all the compose files back in their original places, delete the stacks, move the compose files to their new location and recreate all the stacks. Is this correct? |
Beta Was this translation helpful? Give feedback.
-
|
Hello, I would go one step further and say, that not only the path should be updateable, but (after adding the ability to specify multiple compose files in #2902) it should be possible to remove or add compose fragments to a running stack without deleting and rebuilding it. In our use case, we have (for example) a small compose fragment which only contains the definition to expose the DB container port on the host. By default, a stack's DB container should not be accessible from the outside. But in rare circumstances it may be necessary to temporarily expose the port and connect to it with a client to debug a problem or get some other information. After that, the mapping should be removed again. This could easily be done by leaving out the fragment when the stack is created, add it when an access is required, and remove it again afterwards. As of this moment, we must delete the stack and recreate it with the exakt selection of compose fragments (plus the expose fragment) and the same variables of the orginal stack, and do the same again to revert the change. This is not the only optional fragment which can be applied to our stack. Dynamically adding or removing optional parts is one of the key features of multiple compose files. I understand your original design choice to prevent a stack doing something completely different all of a sudden. But with the addition of multiple compose files, I think that there are more stacks out there which have a lot of optional components. It would be very convenient if those optional components could be switched on and off more easily in portainer. Best regards, |
Beta Was this translation helpful? Give feedback.
-
|
Adding a +1 to this. Not only the path but also potentially the git repository locatin as well. Sometimes the git repo changes such as team migrations etc and the stacks need to be updated to reflect this without taking the stack down. Would be good to get this added as it causes inconvinience and downtime when its not truly warrented! |
Beta Was this translation helpful? Give feedback.
-
|
+1 update the location path of the compose file should be allowed |
Beta Was this translation helpful? Give feedback.
-
|
+1 would be nice indeed to be able to update the path without having to destroy and recreate the stack again. |
Beta Was this translation helpful? Give feedback.
-
|
focdanisch wrote:
☝️ 💯 This just makes sense. |
Beta Was this translation helpful? Give feedback.
-
|
+1 This is absolutely killing me as my repo grows |
Beta Was this translation helpful? Give feedback.
-
|
Please make sure you use the upvote functionality on the parent comment to express your support for this feature request. The more upvotes a request has the more likely we are to implement it. |
Beta Was this translation helpful? Give feedback.
-
|
so many thumbs up around the comments and almost no upvotes in the top comment... |
Beta Was this translation helpful? Give feedback.
-
|
This one just bit me as well with an expired Gitlab token. To update the token of the stack deployment I need to re-create it... |
Beta Was this translation helpful? Give feedback.
-
|
+1 would also like to see this! |
Beta Was this translation helpful? Give feedback.
-
|
To give it a little example of how huge the pain in the ass is here. Let's say we want to deploy a prometheus stack (alertmanager, blackbox-exporter, prometheus, grafana) on a single docker host as Stack (with GitOps) with Portainer. Every single time I want to add another path to (for example) deploy a new set of alert rules for the alertmanager I will have to re-create the whole stack (also with all environment variables) just to add a path to a new file inside the Git-Repository. This far, far away from the idea of "GitOps". @huib-portainer is there at least a way to update these paths "hacky" from the CLI or in the portainer volume, as long as this is not implemented? Or is this some kind of information that is stored inside the database? Edit: Wildcards for additional paths would also work, I guess. Something like...
|
Beta Was this translation helpful? Give feedback.
-
|
+1 would be very great to be able to update the path. |
Beta Was this translation helpful? Give feedback.
-
|
+1 it would be much better if we can update the path |
Beta Was this translation helpful? Give feedback.
-
|
+1 would be very great to be able to update the path |
Beta Was this translation helpful? Give feedback.
-
|
+1 for this feature |
Beta Was this translation helpful? Give feedback.
-
|
Hi All, I have a workaround for this that suited my use case so I thought I would share in case it helps anyone else. Essentially, I am able to rely on docker compose include statements. So your main compose file that the Portainer stack points to cannot change. However, I just have docker compose file consist of a single include statement. For example, consider that you create a wrapper-compose.yaml file and point your Git-based Portainer stack to that. The shell-compose.yaml file would just have the following contents: include:
In this case, I use a relative path to locate the compose file that has my actual contents. Here, I am using a placeholder in the path that can be updated from an environment variable in the Portainer stack or, in my case, a .env file that lives along side the shell-compose.yaml file. So while I cannot change the path to shell-compose.yaml, I can change the contents of shell-compose.yaml to point to a different underlying yaml file. Or, in my case, I update the APP_VERSION variable in the .env file so that it resolves to a different path. As a bonus, I can have multiple shell compose files in the same directory. For example: shell-module1.yaml If the each yaml file represents a different stack in Portainer, you can then use the contents of the .env file to share environment variables between different stacks. This was something I was looking to do as well. |
Beta Was this translation helpful? Give feedback.
-
Is your feature request related to a problem? Please describe.
Currently, I cannot update the path for a stack when deploying a stack utilizing the Git integration. This forces me to recreate the stack, which is inconvenient when all I need Is to change the path to the .yml file in the repo.
Describe the solution you'd like
I would like it to be possible to change the path to the stack file after initially creating the deployment with the Git integration.
Describe alternatives you've considered
Recreating the stack, but is inconvenient.
Additional context
None
Beta Was this translation helpful? Give feedback.
All reactions