Is there any way to deploy a particular version of Kubernetes to ACS in Azure?
Using Azure resource manager, or az command.
It doesn't seem like template format for container service shows this info.
You can specify the version in ACS in selected regions. See the template example.
https://github.com/weinong/azure-quickstart-templates/tree/master/101-acs-kubernetes-with-version
We will be updating azure cli with this feature soon.
I suggest you to use acs-engine in this case. It is a tool for you to specify some custom definition like "orchestratorversion" for your case, and it can then generate an ARM template for deploying the k8s cluster.
You could download the acs-engine tool here https://github.com/Azure/acs-engine/releases (choose the version based on your need for the k8s version).
To achieve your goal, you have to provide a json file which the template you could find here https://github.com/Azure/acs-engine/blob/master/examples/kubernetes-releases/kubernetes1.7.json. You could alter the attribute "orchestratorversion" to either 1.5, 1.6 or 1.7 to suit your need. (or maybe 1.8 for the latest version)
When the json file is ready, you could turn it into the ARM template files by typing the following command
.\acs-engine.exe generate kubernetes.json
This will create a new directory called "_output" and you could find the azuredeploy.json and azuredeploy.parameters.json files there.
For more information about the attributes in the json file, take a look at https://github.com/Azure/acs-engine/blob/master/docs/clusterdefinition.md.
Another way you could also try is in the Deployment via Azure CLI specified here. https://github.com/Azure/ACS/tree/master/docs
Related
I want to use Datadog's Deployment Tracking but to do so I need to dynamically set the version tag. Right now my backend tag is set in the Dockerfile ENV and LABEL and on the frontend it is just in datadogRum.init(). They are currently hardcoded.
I usually do one deployment per day, I would like these version tags to be auto-incremented but haven't found a good way to do it.
I tried using an environment variable from build tools to update these, but could not find a reliable way to do that. I use CodeFresh for backend building and AWS Amplify for frontend.
I'd like to access cluster deployed Helm charts programmatically to make web interface which will allow manual chart manipulation.
I found pyhelm but it supports only Helm 2. I looked on npm, but nothing there. I wrote a bash script but if I try to use it's output I get just a string really so it's not really useful.
I'd like to access cluster deployed Helm charts programmatically to make web interface which will allow manual chart manipulation.
Helm 3 is different than previous versions in that it is a client only tool, similar to e.g. Kustomize. This means that helm charts only exists on the client (and in chart repositories) but is then transformed to a kubernetes manifest during deployment. So only Kubernetes objects exists in the cluster.
Kubernetes API is a REST API so you can access and get Kubernetes objects using a http client. Kubernetes object manifests is available in JSON and Yaml formats.
If you are OK to use Go then you can use the Helm 3 Go API.
If you want to use Python, I guess you'll have to wait for the Helm v3 support of pyhelm, there is already an issue addressing this.
reached this as we also need an npm package to deploy helm3 charts programmatically (sorta whitelabel app with a gui to manage the instances).
Only thing I could find was an old discontinued package from microsoft for helm v2 https://github.com/microsoft/helm-web-api/tree/master/on-demand-micro-services-deployment-k8s
I dont think using k8s API would work, as some charts can get fairly complex in terms of k8s resources, so I got some inspiration and I think I will develop my own package as a wrapper to the helm cli commands, using -o json param for easier handling of the CLI output
I am using a library which searches in registry for a dll. That dll can be installed by running MSI in the Service Fabric cluster and this path will be set.
But I wanted to avoid the installation of MSI in the cluster, and provided the required dlls in the package itself. During start up of the service, I am creating the registry entry and giving the location of the dll in my package. Everything is working as expected.
Is this approach ideal? Are we allowed to make changes to registry? If not, how do we solve this problem? Any pointers are appreciated.
If the library has to use the registry, there is nothing you can do about it other than register the values. If you could change the DLL to retrieve this information from the configuration file would be the ideal solution.
You can do it in SF, the right way to do it is using the SetupEntryPoint option of the ServiceManifest to do these management tasks, and from the Application manifest you can set the policies to specify which user you should run these policies. it is described here with more details
The main issue you have on SF with this approach is that you application might move around the cluster and you have to register it on every node, and maybe also remove it when the application is not running there anymore to avoid garbage in the registry.
I created a sample project using VS2017 "ASP.NET Core Web Application" with Angular.
Then in VSTS I built using Build Template: ASP.NET Core (Build ASP.NET Core Web Application targeting .NET Core). This built successfully and in the artifact section kept the build in a .zip file.
I would like to deploy it to a scale set. So for the Release section I used "Azure Virtual Machine Scale Set Deployment" template. While filling it out there is a field "Deployment Script field" which is mandatory. Not sure what this script is used for and how do i configure in it and where to source the script from.
TL;DR:
This script deploys the content of your deployment package on the virtual machine that you're preparing. In the case of an Angular ASP.NET Core app, this means that you will have to install IIS, the .NET Core Windows Server Hosting Bundle and copy your app to IIS.
Extra info
The Azure Virtual Machine Scale Set Deployment template creates an environment with two tasks:
Build immutable machine image
Azure VMSS: update with immutable machine image
Both tasks have a bunch of fields that need to be configured. Release Management allows you to link important fields to your process. This means that these settings are all grouped under the environment and can be easily set without going through the tasks.
If you look at the following screenshot you'll see that beneath the selected Deployment script field there is a line: This field is linked to 1 setting in 'Build immutable machine image'.
If you look at the documentation for the Build immutable machine image tasks you see the following for the Deployment script:
Deployment Script: Specify the relative path to the PowerShell script (for Windows) or shell script (for Linux) that deploys the package. This script should be within the deployment package path selected above. For example, Deploy/ubuntu/deployNodejsApp.sh. The script may need to install Curl, Node.js, NGINX, and PM2; copy the application; and then configure NGINX and PM2 to run the application.
So this is the script that will automatically deploy your application to a VM. In the case of an Angular ASP.NET Core app, this means that you will have to install IIS, install the NET Core Windows Server Hosting bundle and copy your app to IIS.
I would encourage you to first create an empty Windows Server 2016 VM and experiment with creating a script that prepares the VM and installs your app. Once that's done, you can reuse this script in the Build Image task in VSTS to automate VM and image creation and use that image for your Scale Set.
UPDATE
Your VSTS Build produces an artifact. In your scenario, you are already publishing the zip file with your web application. You can configure the Publish Build Artifacts task to also publish any deployment scripts you want to use during your release. These scripts should be stored in version control. The whole artifact, including your zip file and any deployment scripts you add, is used as input to your Release Definition. The zip file contains your web app as a Web Deploy package that you need to deploy to IIS. This piece of documentation explains how to install Web Deploy and use it to deploy your app.
How do you handle the deployment of a LightSwitch application into a production environment?
i.e. the LS application has been developed, but it now needs to be installed first into Test, and then into Live.
We don't want to use the "manual" approach, i.e. use the Visual Studio Build / Publish option, rather we want to automate the deployment.
My feeling is that deployment is one of the real weak points of LightSwitch. If you are using the very simple deployment model that is build into the product, and you're doing everything within a Windows domain, the publishing wizard can do everything. But if you're deviating from the model at all LightSwitch will fight you. I'd really like to see an "advanced" deployment option that provided some configurability.
Here's how I solved the problem you're having with LightSwitch applications that are targeting web deployment:
At the beginning of the project, deploy once to each target environment using the publish wizard. This is the easiest way to get the database set up.
As new builds are deployed, use the publish wizard to deploy to a deployment package to a standard location on the local development machine.
The deployment package is just a zip file, so you can open it an drill down to where the actual binary release is. I use a powershell script to copy the binary files out of the the deployment package and in to a local SVN working directory. Note that you must not copy web.config file during this step.
Check the unpacked binary files into SVN and use SVN to manage the deployment.
Manage schema changes with SQL scripts.