Support Container App and Registry in different Azure Subscriptions

[jgarplind]

I'm trying to deploy an application to a subscription dedicated to development resources, lets call it Development. However, my registry is centralized and we consider the images to be production-grade resources, hence they reside in another subscription, lets call it Production.

As far as I can tell, there is no way to configure the action to allow the Registry and Container App residing in different subscriptions.

1. Is my observation correct?
2. Is this limitation by design, or rather an unrealized feature that may be supported further down the road?
3. Do you have any suggestions other than co-locating the Registry and Container App in the same subscription that may help in the meantime?

Thanks!

[cormacpayne]

@jgarplind Hey Joel, apologies for the delayed response; when using this GitHub Action, the Container App is created/updated within the subscription that is tied to the credentials that you either provide with the azureCredentials argument or authenticate with prior to the action using azure/login. The ACR instance used by the action is where the runnable application image will be pushed to (if no previously built and pushed image is provided via imageToDeploy) and it's authenticated using acrUsername and acrPassword. The Container App references the ACR instance by pulling this previously pushed image, so there's no need to have them in the same subscription as long as the proper credentials are provided.

With the being said, to answer your questions:

1. You should be able to continue separating the different environments and hosting a centralized ACR instance, all in different subscriptions; for this GitHub Action, you would want to make sure that the credentials you're using to authenticate the calls to Azure are for your Development subscription and the acrUsername and acrPassword arguments you would provide are for this centralized ACR instance that you're using. This will allow the action to build the runnable application image on the runner, push it to your centralized ACR instance and then have the Container App pull it during deployment.
2. This should be answered by the above -- this should currently be supported.
3. For the sake of the issue you're presenting, as mentioned above, the structure you have should currently be supported as long as the correct credentials are provided.

Side note: My two cents for (3): in my experience, we create an ACR instance per environment, so we'd have one for Development and one for Production, which ensures that credentials for pulling and pushing images are not shared across environments (i.e., there's no set of "master credentials" that can access all images). This may make it easier to manage the usage of this action as the workflows could be parameterized to target a specific environment, allowing you to pushes images and deploy a Container App within a singular subscription scope. (These are my personal thoughts and opinions on the matter)

Please feel free to let me know if you still have any questions or if any of the above does not hold true from your usage of the GitHub Action. Thanks!

[jgarplind]

Thanks for your personal thoughts, that is most helpful in getting some perspective.

.. and apologies for the incomplete question that I'm having a bit of trouble re-composing.

All-in-all, I think your answer is great and will hopefully help both me and future users of the action to better understand how to use it.

Feel free to close the issue if appropriate!

[cormacpayne]

@jgarplind Awesome, thanks for following up, Joel. I'm going to close this issue, but feel free to leave any additional comments in the future if anything else comes up. Thanks!