I want to understand the difference between environment and deployment group in Azure Devops.
And when should I use one and not the other?
Thanks
Deployment Groups were the "old way" to do rolling deployment across multiple VMs. The new way is to use environments with the 'rolling' strategy from yaml.
My recommendation would be to let Deployment Groups lie and invest in Environments and YAML.
See:
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/deployment-group-phases?view=azure-devops&tabs=yaml
Related
I want to use an Azure DevOps YAML pipeline to deploy to an AWS stack with EC2 instances and a Load Balancer. I've read here that I can use the AWS userdata script to join new EC2 instances to the Azure DevOps Environment.
My question is, how can I get my Azure DevOps Environment or YAML build to deploy to new servers that join that group? For example, if I use auto-scaling and a new server spins up.
I know that Deployment Groups which are used in the Classic Pipelines had a feature that allowed you to enable a Post Deployment Trigger that could redeploy the last successful build when a new server joined like this.
Is this possible to do with YAML Environments? If so, how?
If it matters, I hope to be able to share the AWS stack and have several separate applications that will get deployed to the same stack with their own YAML builds.
We're migrating our app's deployments from using VMs to Kubernetes and as my knowledge of Kubernetes is very limited, I'm lost how I could set up deployment for multiple clients.
Right now we have a separate VM for each client but how to separate the clients in Kubernetes in a way that will be cost and resource efficient and easy to manage?
I managed to create dev and staging environments using namespaces and this is working great.
To update dev and staging deployment I just use kubectl apply -f <file> --namespace staging.
Now I need to deploy app to production for several clients (50+). They should be completely separate from each other (using separate environment variables and secrets) while code should be the same. And I don't know what is the best way to achieve that.
Could you please hint me what is the right way for that in Kubernetes?
You can use Kustomize. It provides purely declarative approach to configuration customization to manage an arbitrary number of distinctly customized Kubernetes configurations.
https://github.com/kubernetes-sigs/kustomize/tree/master/examples
one (or a set of namespaces) by customer
kustomize has a very good patterns system to handle generic configuration and several adaptation by clients
use NetworkPolicy to isolate network between clients
I need to configure permissions and make use of native features to limit deployment within Azure DevOps, so that those with limited access can only release to dev/test environments and those with privileged access can deploy to all environments, including staging/prod, for example.
I'd like to achieve this without splitting release pipelines up - is it best just to use pre-deployment approvals or is there a better way to remove the ability for those with limited access to deploy into prod, at all?
Can this be done by limiting access to service connections, for example? So a limited user would have 'User' access to the dev/test service connections but not staging/prod, as a safety net?
Just looking for some tips/best practice advice.
Thanks..
You could use deployment groups to handle this.
A deployment group is a logical set of deployment target machines that have agents installed on each one. Deployment groups represent the physical environments; for example, "Dev", "Test", "UAT", and "Production". In effect, a deployment group is just another grouping of agents, much like an agent pool.
When authoring an Azure Pipelines or TFS Release pipeline, you can specify the deployment targets for a job using a deployment group. This makes it easy to define parallel execution of deployment tasks.
Deployment groups:
Specify the security context and runtime targets for the agents. As
you create a deployment group, you add users and give them
appropriate permissions to administer, manage, view, and use the group.
Let you view live logs for each server as a deployment takes place,
and download logs for all servers to track your deployments down to
individual machines.
Enable you to use machine tags to limit deployment to specific sets
of target servers.
Besides, suggest you also take a look at this blog: Configuring your release pipelines for safe deployments which include multiple points:
Gradual rollout to multiple environments
Uniform deployment workflow for all environments
Manual approval for rollouts
Segregation of roles
Health check during roll out
Branch filters for deployments
Secure the pipelines
I'm planning to migrate the deployment process from a traditional deployment tool (Octopus) to Kubernetes and as my knowledge of Kubernetes is very limited, I'm lost how I could set up deployment for multiple clients. I have a CMS-like web-site and I need to deploy it to dev/stage/production for several clients (different servers). Could you please hint me what is the right abstraction for that in Kubernetes?
Option 1 (the easiest): Kubernetes namespace.
Create different namespaces for dev/stage/production. Install same name/label resources there and they will not overlap.
Option 2: Helm chart with the release name tied to every resource. Example chart https://github.com/helm/charts/tree/master/stable/wordpress. When you do this https://github.com/helm/charts/blob/master/stable/wordpress/templates/deployment.yaml#L19 resource references do not overlap even in the same namespace.
Option 3: Do both at time :)
I am looking for best option in handling DEV, TEST, CERT and PROD environments in Kubernetes.
You can use namespaces in Kubernetes. Create one namespace per environment.
http://kubernetes.io/docs/user-guide/namespaces/
Once things get more involved, you can may be move to one cluster per environment, or something like DEV, TEST in a cluster and CERT and PROD in their own clusters.