I have a service in ecs that is being deployed via code deploy (blue/green) I have configured it's rollback parameters to roll back "when a deployment fails". The issue I'm having is that it will attempt to deploy the app, the app will fail to deploy because something was miss configured in the new task definition (in taskdef.json), and continue trying to re-deploy it instead of just rolling back.
This doesn't seem right and the only other thing I can think to do is create an alarm that looks for a failing deployment but that also seems like something that setting the "roll back when a deployment fails" option should do for me. Not to mention creating that alarm doesn't actually seem straight forward either as there would be a few edge cases to it.
Related
I have an ASP.NET Core app and trying to automate deployment to a Linux-based Azure App Service through the on-premises Azure DevOps server. I managed to build everything and deploy the code to the App Service.
At this moment, the Startup Command which should run the application (dotnet dllname) fails. When I open the URL of my web app, I see the default Azure "welcome" page (served from opt/defaultsite).
I don't have a problem with this particular failure - I did not configure the connection string and other settings yet, so it was expected. However, I wonder how it is supposed to handle such failures. I have these concerns:
How do I know that the startup failed without visiting the web app manually? The Deploy task finishes successfully with a green mark despite the fact that the startup was not successful.
When the app fails to start, I would like to see the error message in the browser rather than the default site (at least for the non-prod environments). Otherwise, the only way to understand that I have a problem and see the reason is to go to the Kudu console and see the log stream.
If my app crashes, would it restart it or it will switch to the opt/defaultsite page again?
At this moment, to address the first concern, I am going to add another task to the Stage - a simple PowerShell script which would send a request to one of the app endpoints, however, I wonder if Microsoft suggests some better/more native solution.
Basically, the stage will be failed if there are errors/exceptions during the deployment.
However we cannot fail an Azure Release Pipeline stage if startup command is not successful, because the deployment is actually complete.
As a workaround you can add another task to run scripts to request the endpoints to detect that as you did.
I'm using GitLab CI/CD to automatically transfer the code after every push to the master branch. Everything is going well there. But when Kubernete gets the code, it throws this error message:
Extended error:
I need some help about that.
A CrashLoopBackoff error means that GKE is trying to launch a Pod but the containers within are crashing or being terminated.
There is no simple answer to this. This is a specific error within your application which could be caused by various reasons. You will have to investigate it by looking through the logs.
By the way, I found another thread that looks very similar to yours.
We want to execute external integration tests and manually call a rollback if something is wrong.
We're using the 'Service Fabric Application Deployment' task in Team Services (VSTS) and it seems to only keep the latest in the cluster.
Cluster --> Applications --> [Application], and then under Essentials. Only one row item is listed which shows the latest version.
Also, attempting Start-ServiceFabricApplicationUpgrade results in 'Application type and version not found.'
How do we alter the behaviour of previous version retention of application types? (And what is the default?)
I don't have the answer to your question, but I do offer this thought:
While I understand there may be a valid use case out there for trying to do this, I think a more accepted approach is to set up a test environment that matches production very closely. Deploy to test and test the heck out of it before approving the deployment to production.
One of the main selling points of Service Fabric is its ability to be so redundant, yet with your proposed workflow you are deploying code to that environment in which you're not entirely confident in. I think that really goes against what Service Fabric offers you.
Since you will be testing it so thoroughly on the Test environment, hopefully anything you end up finding in Production is small enough to be fixed through a patch a few hours later or however fast you can fix it.
I've read about partial upgrade, but it always requires to change some parts of the packages application. I'd like to know if there's a way to redeploy a package without version change. In a way, similar to what VS is doing when deploying to the dev cluster.
On your local dev cluster, VS simply deletes the application before it starts the re-deployment. You could do the same in your production cluster, however this results in downtime since the application is not accessible during that time.
What's the reason why you wouldn't want to use the regular monitored upgrade? It has many advantages, like automatic rollbacks and so on.
I'm super new to SCCM and trying out some stuff.
Atm I create a lot of Applications to deploy on around 50 Clients.
Before I deploy them to all clients I test them on a test Client.
The problem now is that if I change sth in the Deployment Type like the installation command I have to delete the deployment everytime afterwards and deploy it again or the change wont happen on the client when I install the Application next time.
There probaly a way easier method which I can't figure out atm.
So how do i update the changes I made after the Application is allready deployed?
Greetings,
Paxz.
The application deployment command line will only be executed if the application is not detected - i.e. the Application Detection criteria evaluates to false. With this premise, it is possible to change the Application Detection criteria so it evaluates to false... perhaps add an addition rule to include "file1.txt exists"? This should work, but it is ugly and I would not recommend it.
A better approach
I prefer to test my application deployments on VMs in the first instance: prepare the destination machine, snapshot it, then deploy.
If you need to tweak your deployment you can then make the required changes, redistribute the content (if required), then restore the VM's snapshot for a fresh deployment.
I managed to get an answer from microsofts technet forum.
For deployments to know the update in the command line, I just have to push the next policy polling cycle.
This will only be effective for clients that haven't executed the deployment type yet.
Other than that there seems to be no other way than deleting the deployment and re-deploying it for the changes to be known for the deployment.