I created a new package for my Azure Managed Application. How do I get existing instances of the Managed Application to upgrade to that package version (mainTemplate.json + viewDefinition.json)?
We were able to talk to a MSFT rep about this today. The information that we got is that any updates to a Managed Application and its resources must be pushed out manually by the publisher by their mechanism of choice (Azure CLI, ARM templates, Azure Portal, Terraform, etc) via the access that the publisher has to the resource group created for the Managed Application.
There is no way to just push up the new ARM template and have that roll out to deployed instances. He said you can re-publish the offer (if publishing via the Commercial Marketplace) with a new template if you want to make the new template available to be used by freshly-created instances, but that this will never affect instances of the Managed Application that already exist.
The rep agreed that the docs that state the following are misleading to how the process actually works:
You can make sure that all customers are using approved versions. Customers don't have to develop application-specific domain knowledge to manage these applications. Customers automatically acquire application updates without the need to worry about troubleshooting and diagnosing issues with the applications.
This "automatic" versioning process is one that the publisher is responsible for implementing on their own. There is actually no concept of versioning built in to Managed Applications.
Related
I've heard about "CloudFormer" tool, to automatically generate a base template from existing resources on the cloud.
https://medium.com/#ridmag/how-to-use-aws-cloudformer-e8d848cfafe1
I can't find this tool in aws! Perhaps this is a old tool that has been removed?
I've heard about another not-Amazon product named "terraform.io" as well. Can Terraform do this? Can it produce a template (in its proprietary format and/or in the cloudformation format) as well?
CoudFormer is no longer maintained and deprecated by AWS. Instead, former2 can be used which is open sourced, developed by AWS Hero and used by AWS clients as explained in AWS blog:
How DNAnexus used the open source Former2 project to create infrastructure as code templates for their disaster recovery pipeline
I'm presently looking into GCP's Deployment Manager to deploy new projects, VMs and Cloud Storage buckets.
We need a web front end that authenticated users can connect to in order to deploy the required infrastructure, though I'm not sure what Dev Ops tools are recommended to work with this system. We have an instance of Jenkins and Octopus Deploy, though I see on Google's Configuration Management page (https://cloud.google.com/solutions/configuration-management) they suggest other tools like Ansible, Chef, Puppet and Saltstack.
I'm supposing that through one of these I can update something simple like a name variable in the config.yaml file and deploy a project.
Could I also ensure a chosen name for a project, VM or Cloud Storage bucket fits with a specific naming convention with one of these systems?
Which system do others use and why?
I use Deployment Manager, as all 3rd party tools are reliant upon the presence of GCP APIs, as well as trusting that those APIs are in line with the actual functionality of the underlying GCP tech.
GCP is decidedly behind the curve on API development, which means that even if you wanted to use TF or whatever, at some point you're going to be stuck inside the SDK, anyway. So that's why I went with Deployment Manager, as much as I wanted to have my whole infra/app deployment use other tools that I was more comfortable with.
To specifically answer your question about validating naming schema, what you would probably want to do is write a wrapper script that uses the gcloud deployment-manager subcommand. Do your validation in the wrapper script, then run the gcloud deployment-manager stuff.
Word of warning about Deployment Manager: it makes troubleshooting very difficult. Very often it will obscure the error that can help you actually establish the root cause of a problem. I can't tell you how many times somebody in my office has shouted "UGGH! Shut UP with your Error 400!" I hope that Google takes note from my pointed survey feedback and refactors DM to pass the original error through.
Anyway, hope this helps. GCP has come a long way, but they've still got work to do.
Ok, so I would like to build my application in a way that allows for each organization to get their own instance.
My way of thinking here, is that I could do something with AWS or digital ocean or whatever to deploy my java (dropwizard) application every time a new client registers their company with us.
This would be virtualized, I would be hoping, so I would have those instances running on various virtual servers.
Basically, when a company registers... I would like to spin up an instance of the core API, and an instance of the DB server (or the two could be one instance here, I guess)
Is this a thing? I would google it, but I am not fully sure what to be looking for!
I know this is not a dropwizard question - but I tagged it this way because it is a dropwizard application I am building - and I figure people in that community may have had similar concerns! Please feel free to edit!
You would need to automate the process of spinning up an environment using something like CloudFormation, Ansible, Terraform, Chef, Puppet, etc. There are a lot of tools in this space. These tools are called Infrastructure as Code (IaC). Once you have it automated, setting up a new environment for a new customer would be a simple task of kicking off the appropriate script.
Amazon Web Services offer a number of continuous deployment and management tools such as Elastic Beanstalk, OpsWorks, Cloud Formation and Code Deploy depending on your needs. The basic idea being to facilitate code deployment and upgrade with zero downtime. They also help manage best architectural practice using AWS resources.
For simplicity lets assuming a basic architecture where you have a 2 tear structure; a collection of application servers behind a load balancer and then a persistence layer using a multi-zone RDS DB.
The actual code upgrade across a fleet of instances (app servers) is easy to understand. For a very simplistic overview the AWS service upgrades each node in turn handing connections off so the instance in question is not being used.
However, I can't understand how DB upgrades are managed. Assume that we are going from version 1.0.0 to 2.0.0 of an application and that there is a requirement to change the DB structure. Normally you would use a script or a library like Flyway to perform the upgrade. However, if there is a fleet of servers to upgrade there is a point where both 1.0.0 and 2.0.0 applications exist across the fleet each requiring a different DB structure.
I need to understand how this is actually achieved (high level) to know what the best way/time of performing the DB migration is. I guess there are a couple of ways they could be achieving this but I am struggling to see how they can do it and allow both 1.0.0 and 2.0.0 to persist data without loss.
If they migrate the DB structure with the first app node upgrade and at the same time create a cached version of the 1.0.0. Users connected to the 1.0.0 app persist using the cached version of the DB and users connected to the 2.0.0 app persist to the new migrated DB. Once all the app nodes are migrated, the cached data is merged into the DB.
It seems unlikely they can do this as the merge would be pretty complex but I can't see another way. Any pointers/help would be appreciated.
This is a common problem to encounter once your application infrastructure gets into multiple application nodes. In the olden days, you could take your application offline for "maintenance windows" during which you could:
Replace application with a "System Maintenance, back soon" page.
Perform database migrations (schema and/or data)
Deploy new application code
Put application back online
In 2015, and really for several years this approach is not acceptable. Your users expect 24/7 operation, so there must be a better way. Of course there is, the answer is a series of patterns for Database Refactorings.
The basic concept to always keep in mind is to assume you have to maintain two concurrent versions of your application, and there can be no breaking changes between these two versions. This means that you have a current application (v1.0.0) currently in production and (v2.0.0) that is scheduled to be deployed. Both these versions must work on the same schema. Once v2.0.0 is fully deployed across all application servers, you can then develop v3.0.0 that allows you to complete any final database changes.
Does anybody of you know if there are any Webservices (or other interfaces) to monitor an, for example ASP.NET application, which is hosted within Windows Azure from a NON .NET environment?
If you're talking about monitoring things like performance counters and diagnostics (logging), those may be accessed from any language, as that information is ultimately stored in table Storage (you need to just set it up in your Windows Azure app as it starts up). Storage is accessed via a REST interface. Additionally, there are SDKs for PHP and Java to facilitate this. There are a few additional open source project I've seen as well - for instance, Ruby.
For a desktop monitoring tool, check out Cerebrata's Azure Diagnostics Manager.
Note: the Management API is also REST-based, so you can control deployments from other languages as well (e.g. scaling instances up/down, stopping/deleting a deployment, creating a new service, etc.). You'll see that the PHP SDK already wraps most of the Management API. See here for detailed API documentation.
Dirk, it depends on what you're trying to monitor. There are many partner products like AzureWatch from Paraleap that can monitor applications in Windows Azure, or you could always write an application yourself to monitor your Windows Azure application using the Windows Azure APIs (try AzureMonitor on CodePlex] as a start). You can find out more information about Monitoring on MSDN and the Windows Azure Managed Library Reference.