0

I have been burning my remaining neurons during the last week with this issue. The challenge that I am facing is that I am trying to upload or push a modified container to my Azure Container Registry using Azure DevOps pipelines without undoing the changes made by the Release Pipelines tasks. So, on the Build Pipelines "side", I create an image which I push to my ACR, which works really good, despite the size of it. The problem comes when, after downloading the same image on the Release Pipeline "side", creating a container and doing some changes to it through powershell cli tasks, I try to deploy it to my Web App Instance. When I try this last step, all the modifications made are lost, since, apparently, the is another "pull" call made by the deploy task, which ovewrites all the implementation that I just made. I have seen that I can "move" containers around with "commit" or "export" and "import", but thats not the idea, since my main goal is to deploy that "modified" container to my web app. Finally, I am not supposed to create a new image on the Release ppln side, but rather work with the existing one -created by the Bld ppln- and do all the changes through code, like powershell tasks on the Rls ppln side.

Daniel Mann
  • 57,011
  • 13
  • 100
  • 120
Lee Andrew
  • 35
  • 8
  • 1
    I'm having a hard time understanding your use case. A container image is supposed to be immutable which is why any changes you make to it during the Release Pipeline are lost. Your Release Pipeline should be deploying your container image to something like Azure Container Apps. Could you clarify your question with what your goal/objective is for modifying the container image in the Release Pipeline? – tj-cappelletti Feb 24 '23 at 13:30
  • Hello, Tj. Thanks for your reply and sorry I wasnt able to fully expose my issue. Well, the idea, basically, is to work with only one image and all the publish that we need to do has to be done in a container, rather than creating one image for every publish transform (we have about 11 with about 7 environments for each one). So, at the end of the day, the main goal is to decrease the complexity of having 50+ images by using and have only one image and do all the "transforms" inside the different containers. What I had to do, is that I created a temporary image, some sort of "base" one... – Lee Andrew Feb 24 '23 at 13:52
  • So, putting in a short sentence: Is there a way to make containers temporally "statefull" up to the deployment/publishing ? – Lee Andrew Feb 24 '23 at 13:58
  • Just to make sure I understand correctly, the need to modify the container image is to update the configuration to make environment specific. Is that correct? – tj-cappelletti Feb 24 '23 at 15:08
  • Hi again, TJ. Again, thanks for the reply. Yes, the idea is exatly that one. I am also considering the option of volumes. However, as I said b4, the idea is to make it as simple as possible since we are dealing with 50+ web transforms. – Lee Andrew Feb 24 '23 at 15:48
  • 3
    Configuration should be mapped into the container via environment variables or a volume mount. If you are managing extensive configuration transformation, it may be worth investing some effort in finding ways to simplify your application's configuration. – Daniel Mann Feb 24 '23 at 17:21
  • Thanks so much for your replies. Yup, I had to choose the volume mount approach. Again, thanks for your ideas. – Lee Andrew Feb 28 '23 at 13:24

0 Answers0