I have a running stack on docker swarm. At start it was created from docker-compose.yml files. From time to time I would have run some one-off docker service update commands without updating the docker-compose.yml files because I felt confident that way it won’t do some unnecessary steps due to my negligence. By now it seems I have done a lot of updates that I just want a fresh docker-compose.yml based on the current state, felt reasonable to have that as a starting point to figure out the changes made from the old files. Is there a way to do that?
I thought I could use the docker service inspect but it lacks yaml format, just wondering if there’s a better alternative.
Would you like to use that yaml to copy to your docker compose file? Since the docker service inspect gives you an output which is incompatible with Docker Compose (and not because of its format), you would not be able to do that. If you just want to convert json to yaml, you can use yq.
pip3 install yq
docker service inspect SERVICENAME | yq -y
I don’t think you could see all your changes except your last limited number of changes if your task history is not disabled.
docker service ps SERVICENAME
Then you can use the id to inspect the old services
Swarm services created by a stack should be exlusivly maintained within the stack compose file. There is no reason to use docker service update for service created by a stack at all. Configuration changes in a stack will be applied on the next docker stack deploy execution - at the end the same api’s will be used under the hood that `docker service create/update) uses.
I am afraid you will have to inspect the ouputs of each docker service inspect and identify the drift and manualy add identified changes to your stack compose file.
Would you like to use that yaml to copy to your docker compose file?
Yes, sorry I didn’t make that clear in my OP. Indeed what I’m looking for is a way to convert from docker service inspect to Docker Compose file (which is in yaml format eventually). But like you said that currently docker service inspect does not have that kind of thing, though I thought that because I was able to understand the Spec field in the output, I realized that many of the fields and values are coming from the Docker Compose files or the docker service update commands, and others are probably default values which I’m OK with having all of that info in a Docker Compose file.
I don’t think you could see all your changes except your last limited number of changes if your task history is not disabled.
I realized that the history is limited, and to be frank there were sometimes where I had to run docker service update <service> --force as means of “re-starting” the service for some reasons like node shutdowns or load balancing and such, I know that this approach isn’t ideal and this was adding un-changed service history.
I’m not so worried about Docker giving me the history of changes, I could think of a way of using external tools like WinMerge or diff and rely on my memory to figure out the differences from what I started with to what I have at the moment. But it is for the reasons I mentioned that I’m looking into a way of getting the “current state” Docker Compose file so I could have a starting point of comparing it with my old files and updating them.
Based on that, I may just have to go the manual way of checking each field in Spec (from docker service inspect) and figuring out its equivalent in Docker Compose definition.
I understand that, but like I mentioned in my OP, updating the stack compose file and running docker stack deploy has way more “magic” things going on (in Docker, because my entire service stack is defined in the file) compared to just running docker service update to specific service in focus (just update, I never use create because initially I used docker stack deploy). When I first got into Docker, I did the updates by updating the stack compose file, but I realized that some of the services that I thought I didn’t change where being restarted causing failures which were unnecessary in my opinion. I didn’t give much attention to why this was happening because I then learned docker service update and what I can use it for. From time to time, I changed some labels, constraints, scaled up or down, environment variables and such. It felt simpler (less magic to worry about), more “directed” or scoped and focused doing them using docker service update than updating the stack compose file and running docker stack deploy. From your comment I can tell that there might be things I should know about to improve, I don’t think I will be focusing on that right now but I am all ears.