At the company that i work, they deploy applications to azure using Azure App Services.
This involves creating the App service manually, and setting up the pipelines manually.
My question is if there is another way to host and run applications in Azure without using App Services?
The reason for this is that i don't like the manually work when setting up a app service and all it's configuration.
Any suggestions?
What you actually need is setting up CI/CD pipelines for your application to create resource(AppService in this case) and deploy on them.
If you are new to Azure Devops, i would highly recommend to explore Devops starter service to deploy your application with few clicks and see how it creates resources and pipelines automatically
On the 2nd question, there are many compute options available on Azure such as Virtual Machines , AKS (Containers Orchestration) , Container instances etc.
You can explore those compute options using the decision tree here
Related
We currently use a very traditional deployment methodology. Developers build EXE packages which are then handed to the operations team who install it onto VMs (one VM per customer). Our company is B2B and resources between customers is rarely shared.
Now, we are looking at using Azure App Services to deploy software.
I can deploy our app to Azure App Services, but what is the recommended way to deploy to many customers? The documentation online talks a lot about continuous deployment, so is the expectation that we maintain deployment profiles for each customer?
I would start with exploring the AZ-CLI to script creation of AppServices. Then use the AZ-CLI to deploy your apps to the different customer app services. With regards to the different customers: I would start with an AppService per customer within a single App Service Plan, in that way you can limit the costs for now.
We use Azure DevOps build and release pipelines for creating (and updating) App Services and also for building and deploying to these app services. Based on certain conditions we first deploy to Development, after approval gates to Test, QA and finally Production. Nowadays we use YAML pipelines for most tasks, but we started with Azure Portal and AZ-CLI. It takes time to evolve from manual deployment to fully automated.
Deploying a multi-container application to Azure Kubernetes Services without using Azure DevOps
We have use case with Java Application (Spring ) with oracle Database as two containers .
We have to try the same in AKS ( Not using Azure DevOps).
Both App (8080) and DB (1521) runs on different Ports
Let me know if you have similar use case implemented.
The point of discussion here might be that whether you want to use a CI/CD Tool other than Azure Devops or not?
If yes, you'll need to setup a pipeline, write some Kubernetes Templates, Build Code, Push Image, and then deploy.
You can always refer Kubernetes Official Docs for more in depth knowledge of Multi-Container Pods, and Jenkins Official Docs for understanding CI/CD Process
If an App Service Plan containing an App Service is horizontally scaled in Azure (using Monitor - Auto scale functionality) how does that affect future deployments via Octopus if the "Deploy to Azure" step is used. Would any deployments automatically get deployed to all scaled instances in Azure without us having to do any more configuration in Octopus?
Octopus will not automatically deploy to scaled instances without configuration. You will need to configure Octopus to automatically deploy to targets using project triggers. You can find documentation on using project triggers here: https://octopus.com/docs/deployment-process/project-triggers/automatic-deployment-triggers and documentation specifically concerning auto-scaling infrastructure here: https://octopus.com/docs/deployment-patterns/elastic-and-transient-environments/keeping-deployment-targets-up-to-date
I have some experience in using azure app services without docker. I did worked on k8 with docker. Now I am seeing an option to deploy containers in azure app services. As per my understanding app services internally use container and orchestration engine. Now someone can explain why this new docker option in azure app services? How it is going to help? When to use this option? Why I should bundle it as docker(extra effort eventhough it trivial)?
Azure App Service on Linux (Web App with built-in images)
The built-in image option running on Linux is an extension of a current Azure App Service offering, catering to developers who want to use FTP or GIT, deploy .NET Core, Node, PHP or Ruby applications to Azure App Service running on Linux
All of the built-in Docker images are open sourced on GitHub and available on DockerHub
Now someone can explain why this new docker option in the azure app
services?
Web App for Containers is catered more towards developers who want to have more control over, not just the code, but also the different packages, runtime framework, tooling etc. that are installed on their containers.
Customers of this offering prefer to package their code and dependencies into containers using various CI/CD systems like Jenkins, Maven, Travis CI or VSTS, alongside setting up continuous deployment webhooks with App Service.
This way you can easily deploy and run containerized applications that scale with your business.
How it is going to help?
This will make sure that the environment that you use locally, is
exactly the same as the one in the cloud.
Just pull container images from Docker Hub or a private Azure
Container Registry and Web App for Containers will deploy the containerized app with your preferred dependencies to production in seconds.
Automate and simplify your container image deployments through
continuous integration/continuous deployment (CI/CD) capabilities
with Docker Hub, Azure Container Registry, and Visual Studio Team
Services
Automatically scale vertically and horizontally based on application
needs. Granular scaling rules are available to handle peaks in
workload automatically while minimizing costs during off-peak times
When to use this option?
If you are so passionate/familiar with Docker/container then you can
use the Azure App service with the container.
If you are planning to host all your container in ACS(Azure Container
Service)/GitHub Repository then this service might be useful
You can refer to this blog for more details
I got a cloud service (worker role) which I want to deploy to a beta and a production environment.
It seems a waste to have to create three projects (one with the actual implementation and two for deployment).
Is it possible to create two deployment profiles which links to different Azure destinations but uses the same worker role project?
This is very simple to do. Just build your Azure package without deploying, and keep your dev/beta/prod settings in the Service Configuration, not embedded anywhere like web.config/app.config. Then store both the deployment package and configuration in blob storage (speeding up deployment). You'll want multiple configuration files: one for each environment, each stored separately in blob storage.
Once this is done, you can just deploy the package to multiple cloud services, each with a different configuration file. This can be done either through the portal or through PowerShell / CLI.
If you've been deploying directly from Visual Studio, it might not seem quite as obvious. But from VS, you can build a package without actually deploying.