0

New to Azure, I'm looking for a good way of deploying our apps. The situation is that we build our Java apps inside our network using Jenkins. Each successful build should be automatically published to the production environment on Azure. We cannot have any port opened from our network to Azure other than https. To make it even worse, we need to go through an http/s proxy. Note that we can only deploy compiled war-files. No code is allowed to be published outside our network.

What would be the options in our case?

Johan
  • 756
  • 5
  • 20

1 Answers1

1

Your issue isn't really the WAR file, that's pretty easy to deal with. Once you setup an Azure web app to run Java if you drop the WAR in the root of an Azure web app then it will get loaded and deployed.

The issue your going to have is getting it up to Azure with only outbound https allowed. You can't use any of the deployment mechanisms built into Azure Web Apps as they don't run on port 443.

The only thing I could think of would be to have your build process upload the file to Azure storage, which does use outbound 443. Then you could create an Azure automation Powershell job that takes the file from storage and publishes to the web app using web deploy or ftp or similar. You could have your build process trigger this by setting up your automation job with a webhook, which you can hit from your build server as it's running on 443.

Sam Cogan
  • 38,736
  • 6
  • 78
  • 114
  • Reason why I talk about the war file is that if we could host the code at Github or other public repo, we could build it all within Azure. That is not an option however, for obvious reasons. I was actually investigating the blob storage after I asked the question, and it seems like a fit. Good to see your confirmation on being on right track. I'll update with the status as it progresses. – Johan Mar 28 '17 at 18:55
  • Wow, this is a jungle. Would you mind pointing me in the right direction regarding setting up the Azure automation powershell job? I don't get all the concepts right I think. Is the "runbook" concept relevant? – Johan Mar 29 '17 at 09:17
  • Sure, it should be fairly straightforward so long as your familiar with PowerShell. You should just need to create an automation account in the portal, and then create a run book and setup any variables you need (usernames etc.). Whats the specific issue your having? – Sam Cogan Mar 29 '17 at 09:19
  • The specific issue is that I don't know the concepts of Azure. Took me a while to understand I need an Automation account in the first place. Second issue is likely that I have no knowledge of PowerShell. But now I guess I'm on track again. – Johan Mar 29 '17 at 10:59
  • Ok, what's the language you are most comfortable with? You could instead use Azure Functions, these are essentially serverless compute that allow you to run small pieces of code on an event (like a webhook), this might be better suited in that it allows you to write the code in a number of different languages – Sam Cogan Mar 29 '17 at 11:01
  • Well, I guess it cannot be that hard no matter choice of language. If translated to bash, I guess it would be a oneliner like: `scp $BLOB_URL:myApp.war . && scp myApp.war $TOMCAT_MACHINE:/webroot` or similar? – Johan Mar 29 '17 at 11:18
  • Well it's going to be a bit more complicated than that, as your script isn't running inside the web app, so you would need to fetch the file from blob storage, and then push it to the web app using FTP or Web deploy. I'll have a go at writing something that could do this. – Sam Cogan Mar 29 '17 at 11:55
  • Also, this article might be helpful: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-application-proxy-enable – Net Runner Mar 29 '17 at 19:55
  • @NetRunner, thanks, but that does not seems to be for deployment but rather application authentication. Besides, it requires network configurations that are way out of our possibilities. Only https port 443 is allowed as outbound, and the traffic must go via a proxy. – Johan Mar 30 '17 at 07:14
  • Yeah, I can't see how App Proxy would help here, unless you were looking to abandon the publishing to Azure part and have it hosted internally, but accessible from outside. But you'd still need more outbound ports than you have open. – Sam Cogan Mar 30 '17 at 07:57