I'm looking for an equivalent to Cloud Run (GCP offering) in Azure
In particular:
It deploys a container
Can scale down to 0
Can serve a webapp
Does Azure have such a service?
I was looking at Azure App Service, but it seems to be missing the ability to scale down to 0.
Azure Container Apps is similar to CGP Cloud Run.
It deploys a container: yes
Can scale down to 0: yes
Can serve a webapp: yes
https://azure.microsoft.com/en-us/services/container-apps/
I think the equivalent of Cloud Run would be Azure Container Instances rather than Azure Container Apps.
I would say Azure Container Apps would be the equivalent of App Engine from Google Cloud which comes with more managed services around the served container like authentication, etc...
If one is running Docker Enterprise with Kubernetes in an on-premises private cloud, is it possible to add clusters in a public cloud like Azure?
On GCP, Anthos is a candidate.
You may have a look on their architecture and see if it fits your needs.
Anthos is advertised in most of the GCP architecture courses and offers integration between GKE and both on-prem(the on-prem cluster must meet some prerequisites or you can use the version provided by Google) and AWS Kubernetes clusters.
Istio is a service mesh and if I understood correctly your requirements, the multiple clusters and multiple networks models could be used.
why don't use rancher for that , you can manage on-premise and GKE AKS EKS or cluster installed in ec2.
it's a great tool for that
This is where Azure Arc can help you to achieve this requirement. However it is in preview stage as of now, i hope soon it will be generally available.
From the DOCS,
You can attach and configure Kubernetes clusters inside or outside of
Azure by using Azure Arc-enabled Kubernetes Preview. When a Kubernetes
cluster is attached to Azure Arc, it will appear in the Azure portal.
It will have an Azure Resource Manager ID and a managed identity.
Clusters are attached to standard Azure subscriptions, are located in
a resource group, and can receive tags just like any other Azure
resource.
cluster API under kubernetes SIG is an open source project which provides declarative APIs and tooling to simplify provisioning, upgrading, and operating multiple Kubernetes clusters.
Cluster API can be extended to support any infrastructure provider (AWS, Azure, vSphere, etc.) or bootstrap provider (kubeadm is default) you need. There is a growing list of supported providers available.
You can use cluster API and build your own custom management plane based on cluster API if vendor provided software is not an option for you.
If you are looking for a vendor provided management plane which can be hosted on prem and can manager life cycle of a on prem kubernetes cluster as well as a cluster on any public cloud provider such as AWS, GCP, Azure then Tanzu Mission Control from VMware is an option. Internally it uses cluster API.
Personally I would not use Anthos or Arc because they seem to be a way to get locked into a specific vendor
I just deployed a web app (node.js container and mongo container) using Azure multi-container instances. It's a bit like Docker Compose but works with an Azure specific yaml file: https://learn.microsoft.com/en-us/azure/container-instances/container-instances-multi-container-yaml
Now I see that there is something called "Azure Web App for Containers". This seems to work with a real docker compose yaml file.
Other than the configuration file format, are there any other differences?
Note: I'm talking about Azure container instances, not Azure container services.
Well, azure container instances bill you only for the time container is active, while webapp bill you for the time webapp exists (so all the time). that is one of the biggest differences between those.
But overall, I'd say Azure Web App for Containers is just a shortcut to run containers on existing "stuff". I've recently learned that Azure Web App for Containers offer kubernetes capabilities, so these 2 services evolve in a slightly different directions. Azure Web App for Containers is targeted at long running stuff (always running) while ACI are aimed at scheduled\burstable\short lived workloads (similar to Azure Functions).
Found this link with MS-staff answer.
In summary
Web App for Containers
Recommended if you are already familiar with the Azure Web App environment.
Best if you have one or a few long-running containers/services that are being deployed.
Can use a custom Docker image to run your web app on an application stack that is not already defined in Azure
Azure Container Instances
"Azure Container Instances is a great solution for any scenario that can operate in isolated containers, including simple applications, task automation, and build jobs"
A fast, light-weight and easy way of running containers
Billed for the time your container is active (billing is based on seconds, cores and memory)
Can start containers in Azure in seconds, without the need to provision and manage VMs.
Can also work with Kubernetes through an experimental ACI to Kubernetes connector
Currently, the fastest way to deploy containers on Azure
Based on the Azure docs, " Azure Container Instances guarantees your application is as isolated in a container as it would be in a VM."
Another difference, in addition to the other answer, is that Web App for Containers offers "slots" with which you can run multiple images on the same allocated resources to help increase utilization. As container instances bill per time used, they do not have "slots".
There is a good article about this on Microsoft Learn called: Comparing Container Apps with other Azure container options
Azure Container Instances
Azure Container Instances (ACI) provides a single pod of Hyper-V isolated containers on demand. It can be thought of as a lower-level "building block" option compared to Container Apps. Concepts like scale, load balancing, and certificates are not provided with ACI containers. For example, to scale to five container instances, you create five distinct container instances. Azure Container Apps provide many application-specific concepts on top of containers, including certificates, revisions, scale, and environments. Users often interact with Azure Container Instances through other services. For example, Azure Kubernetes Service can layer orchestration and scale on top of ACI through virtual nodes. If you need a less "opinionated" building block that doesn't align with the scenarios Azure Container Apps is optimizing for, Azure Container Instances is an ideal option.
Azure App Service
Azure App Service provides fully managed hosting for web applications including websites and web APIs. These web applications may be deployed using code or containers. Azure App Service is optimized for web applications. Azure App Service is integrated with other Azure services including Azure Container Apps or Azure Functions. When building web apps, Azure App Service is an ideal option.
Azure Web App for Containers and Azure Web App is the same service and they use an App Service Plan. The only difference is that Publish is set to Docker Container instead of Code by default.
https://azure.microsoft.com/en-us/products/app-service/web/
https://azure.microsoft.com/en-us/products/app-service/containers/#overview
From the article to see other alternatives as well:
There are many options for teams to build and deploy cloud native and containerized applications on Azure.
Azure Container Apps
Azure App Service
Azure Container Instances
Azure Kubernetes Service
Azure Functions
Azure Spring Apps
Azure Red Hat OpenShift
Azure Container Apps
Azure Container Apps enables you to build serverless microservices based on containers. Distinctive features of Container Apps include:
Optimized for running general purpose containers, especially for
applications that span many microservices deployed in containers.
Powered by Kubernetes and open-source technologies like Dapr, KEDA,
and envoy.
Supports Kubernetes-style apps and microservices with features like
service discovery and traffic splitting.
Enables event-driven application architectures by supporting scale
based on traffic and pulling from event sources like queues,
including scale to zero.
Support of long running processes and can run background tasks.
Azure Container Apps doesn't provide direct access to the underlying Kubernetes APIs. If you require access to the Kubernetes APIs and control plane, you should use Azure Kubernetes Service. However, if you would like to build Kubernetes-style applications and don't require direct access to all the native Kubernetes APIs and cluster management, Container Apps provides a fully managed experience based on best-practices. For these reasons, many teams may prefer to start building container microservices with Azure Container Apps.
You can get started building your first container app using the quickstarts.
Azure Kubernetes Service
Azure Kubernetes Service (AKS) provides a fully managed Kubernetes option in Azure. It supports direct access to the Kubernetes API and runs any Kubernetes workload. The full cluster resides in your subscription, with the cluster configurations and operations within your control and responsibility. Teams looking for a fully managed version of Kubernetes in Azure, Azure Kubernetes Service is an ideal option.
Azure Functions
Azure Functions is a serverless Functions-as-a-Service (FaaS) solution. It's optimized for running event-driven applications using the functions programming model. It shares many characteristics with Azure Container Apps around scale and integration with events, but optimized for ephemeral functions deployed as either code or containers. The Azure Functions programming model provides productivity benefits for teams looking to trigger the execution of your functions on events and bind to other data sources. When building FaaS-style functions, Azure Functions is the ideal option. The Azure Functions programming model is available as a base container image, making it portable to other container based compute platforms allowing teams to reuse code as environment requirements change.
Azure Spring Apps
Azure Spring Apps is a platform as a service (PaaS) for Spring developers. If you want to run Spring Boot, Spring Cloud or any other Spring applications on Azure, Azure Spring Apps is an ideal option. The service manages the infrastructure of Spring applications so developers can focus on their code. Azure Spring Apps provides lifecycle management using comprehensive monitoring and diagnostics, configuration management, service discovery, CI/CD integration, blue-green deployments, and more.
Azure Red Hat OpenShift
Azure Red Hat OpenShift is jointly engineered, operated, and supported by Red Hat and Microsoft to provide an integrated product and support experience for running Kubernetes-powered OpenShift. With Azure Red Hat OpenShift, teams can choose their own registry, networking, storage, and CI/CD solutions, or use the built-in solutions for automated source code management, container and application builds, deployments, scaling, health management, and more from OpenShift. If your team or organization is using OpenShift, Azure Red Hat OpenShift is an ideal option.
We are looking into migrating all our company services to Kubernetes. Since it seems to be pretty straight forward to setup I was looking into Azure Kubernetes Service.
Out of curiosity and with certain privacy issues in mind, I was wondering if it is possible to add self-hosted nodes to the Azure Kubernetes cluster and if so, how to do it.
No. All nodes in the cluster must run in Azure and are managed by the AKS service, though they reside in your subscription.
I deployed an Azure Worker Role running OWIN into a Cloud Service for very fast HTTP serving. The Cloud Service exists in the "classic" environment at manage.windowsazure.com.
I would like to deploy the same lightweight application using the new ARM bits so it can be fully managed at portal.azure.com. I don't want to use a Web Application because that includes IIS.
What is the correct Platform-as-a-Service object to use in the ARM and the new portal that gives the same performance as an old Cloud Service Worker Role?
Thanks.
There isn't a Platform-as-a-Service object to use for this in ARM. Some Infrastructure-as-a-Service options are:
Create a regular Windows Azure Resource Manager VM in the new portal and set it up as an OWIN host.
Create an Azure Resource Manager template to deploy an OWIN host to a VM or a VM Scale Set. The template would use the custom script extension and/or DSC to do the setup. This would be a good re-usable solution, but someone would need to write the template for the first time.
The lightest weight solution would be to have the server running in a Docker container on Windows. You could then choose use the VM for other purposes running in other containers or purely as a container host. Note this only runs on only runs on Windows Server 2016 Technical Preview 3. See http://anthonychu.ca/post/web-api-owin-self-host-docker-windows-containers/
Edit -
Note that Service Fabric is the recommended PaaS solution in Azure Resource Manager. It is not a direct equivalent of PaaS v1 but a rich service for developing micro-service based applications: https://azure.microsoft.com/en-us/documentation/services/service-fabric/
Not sure what you mean by V2 (new portal? ARM?). The portal is an independent tool, so I'm guessing you mean ARM. ARM doesn't support Cloud Service deployments currently, but you can still deploy either from Visual Studio (using the same interface you've used in the past, in visual studio) or from the portal, as a "classic" resource (which, underneath, uses the classic Azure management API).
In the portal, you'll find Cloud service (classic):
Now you can add a new cloud service:
And fill out the various parameters: