I'm automating the deploying of Azure Resource Groups and Virtual Machines. I'd like to have a Ansible Controller recognize when new VMs are created so that it can run playbooks on them and configure them for me.
How do I get Ansible to recognize new VMs created in Azure
No, Ansible on its own can't do that.
Ansible is an agentless tool that do the job only when you (or some other external system) ask it to.
You have some options:
setup some monitoring system that will watch for new VMs and trigger Ansible playbook runs
setup some cloud events (not sure if there are any in Azure, like CloudWatch Events in AWS) that will trigger your Ansible jobs
setup dynamic inventory for your playbook (that will list all VMs provisioned and new) and run your playbooks with cron Job
setup ansible-pull inside your cloud VM images, so it pulls required playbooks at VM startup and provision machine automatically
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.
I am able to successfully deploy Service Fabric services to my local cluster from Azure Devops using the ServiceFabricDeploy task with a configured service connection. What I need is the ability to run some arbitrary powershell scripts against the fabric in order to perform other maintenance tasks that I want to automate via CI/CD.
How can I get a normal inline powershell task connected to my local fabric so I can interact with the cluster?
You can use the SF PowerShell module for that.
First connect to the cluster.
Next, manage the cluster using the provided functions.
Under water, these commands use the REST API of SF. Therefore you can't just run arbitrary code.
If you want to do that, you'll need to use SSH or something like PowerShell remoting.
More info on how to set it up in the Load Balancer here.
We have a Service Fabric cluster on-premise and would like to deploy code to it from Visual Studio Team Services. We use this cluster for testing and it does not have an endpoint exposed to the outside world. It is only accessible internally from inside our network.
From inside Team Services the normal way to deploy a Service Fabric application is with the "Service Fabric Application Deployment" task. This task requires a "Cluster Connection" parameter, or link to the Service Fabric Service endpoint that Team Services can access. On this cluster I can't provide an endpoint to the outside world, so this method won't work.
Is there a good, accepted way of accomplishing this? I'm considering looking at having an Agent on one of the Service Fabric nodes that can run a PowerShell script as part of the build process. I can kick off a PowerShell script on the node as part of the build process. If I could retrieve the artifacts from Team Services with this script I believe the rest of the release would be relatively straightforward.
Is this a good line of thought, or is there a more straightforward way to deploy to Service Fabric from Team Services without exposing an endpoint?
We have the same set up and using VSTS. We set up a On-Prem agent pool where agent is within our network. The agent is hook with VSTS so build and release can be trigger from VSTS. Agent have access to the artifact on VSTS and can download it for deployment. The different might be we set up a service fabric end point instead of using powershell.
Its a very simple set up and works well for us.Good luck
I want to use an azure automation account to connect to a service fabric cluster and run a health check. I'm struggling with establishing a connection to the cluster because the service fabric sdk is not present.
Is there a way to use the service fabric powershell cmdlets in an azure automation runbook?
You could import AzureRM.ServiceFabric 0.2.4 module to Azure automation account. Open the link https://www.powershellgallery.com/packages/AzureRM.ServiceFabric/0.2.4 and click Deploy to Azure Automation. Then, you could use some Service Fabric PowerShell cmdlets.
Another solution is using Hybrid Runbook Worker.
The Hybrid Runbook Worker feature of Azure Automation allows you to
run runbooks directly on the computer hosting the role and against
resources in the environment to manage those local resources.
You could install fabric cluster SDK on your local, and use Runbook worker to execute it.
I have a bit of trouble finding differences about Azure and on-premise Service Fabric versions. I did read somewhere that on-premise version does not support auto-scaling, but this is easy to understand.
However, does on-premise version offer any type of operational capabilities such as resource managers, visual management of cluster, etc.?
The core Service Fabric platform is simply a runtime that gets installed on a set of virtual or physical machines. Once you tell those machines how to find each other, they form a cluster and provide a set of management capabilities that includes the Service Fabric Explorer UI, a REST API, and a TCP endpoint for PowerShell. All of that is common whether you're running on Azure, on-premises, or in another public cloud.
What's different in those environments is everything that lives outside of the machines that form the cluster. That includes:
Autoscaling
While Service Fabric can easily handle new machines being added and removed from the cluster, it has no knowledge of how that process actually works, so some external agent needs to handle it. In Azure, that's a virtual machine scale set.
Failure domain/Upgrade domain management
Good management of failure and upgrade domains is critical to ensuring availability and data reliability in Service Fabric. In Azure, clusters are automatically spread across FDs/UDs and maintenance is coordinated to avoid impact to your clusters. In other environments, this is your responsibility.
Cluster setup and management
In Azure, a Service Fabric cluster is a 1st class resource that can be created and managed through the Azure Resource Manager and the Azure portal. Outside of Azure, you must do that management using the cluster configuration JSON template.
Incidentally, just so there's no confusion since there are overloaded terms... you can't currently use the Azure Resource Manager (ARM) with Service Fabric outside of the Azure environment. However, Service Fabric's cluster resource manager is part of the core runtime and is available everywhere.
Diagnostics pipeline
By default, Service Fabric logging (on Windows) is done via ETW. However, without any component to pick up those events from the individual machines in the cluster and ship them somewhere for easy aggregation and inspection, the logs aren't very useful. In Azure, that process is handled by the Windows Azure Diagnostics (WAD) agent, whereas in other environments you are responsible for setting up that pipeline.
You don't get to use the resource manager on premises. You can access the Service Fabric Explorer at port 19080.
https://azure.microsoft.com/en-us/documentation/articles/service-fabric-deploy-anywhere/
https://azure.microsoft.com/en-us/documentation/articles/service-fabric-visualizing-your-cluster/
Powershell management & deployment will also work.