I was going to deploy my Cloudformation stack from the Cloudformation service but decided to try out Application Manager due its features like application monitoring, drift status, etc. However, I noticed before I provisioned my stack that Application Manager does not contain any of the sections that Cloudformation service console does. Does anyone know if 1. Systems Manager Application Manager has the Stack failure options, Stack policy, and Rollback configurations settings during the CF stack launch process like the Cloudformation service console does? 2. If I just use Cloudformation service console for launching my stack will Application Manager "pick it up" as an app or do I have to adhere to a certain configuration to get my stack into Application manager after it is launched.
Related
I had deployed the app last on friday and it got deployed successfully.But since, today morning the deployment is not happening at all.It is checking for conflicting process and failing.
I'm doing this from the webide and i'm not able to check what are the conflicting process and how to resolve it.
WebIDE lacks the ability to do proper investigation on deploying apps to SAP Cloud Foundry.
The best way to do this is to install the Cloud Foundry Multi-apps plugin (see this tutorial). This will allow you to use the local terminal to control the deployment (or alternatively use SAP Business Application Studio which already has the commands built in).
Then use the command cf mta-ops to get the list of ongoing operations and cf dmol <operation_id> to download the logs for that operation. cf deploy can be used to abort/retry operations.
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 followed the instructions on IoT Asset Tracking on a Hyperledger Blockchain . BUILD and DEPLOY finished successfully, but I can't find the composer-rest-server- app under Cloud Foundry Applications.
I can use the CF Blockchain services, enter the Monitor and open the Swagger UI. The question is, where can I find the application-specific APIs mentioned in the tutorial:
If everything deployed correctly, you can find the app in the IBM Cloud dashboard at https://console.bluemix.net. If you have many apps and services deployed, make sure to filter correctly or to be aware of paging.
If you suspect that something got wrong during build and deploy, go to the toolchain and check the logs. The toolchains can also be reached from the dashboard.
I have created a MobileFirst starter app on the Bluemix platform. I am using the default code generated on an app creation. On app start, cf logs <appname> shows
ERR Instance (index 0) failed to start accepting connections
Is there any issue with the US-South region?
What could be causing this issue?
We are not aware of any ongoing issue in US South as you can see on the Bluemix Status Page. I've just tried to create a new application using the MobileFirst Services Starter (leaving all the default settings): I'm able to see the example "HelloTodo" page and there are no errors in the logs. I used both the Classic UI and the "New Experience" UI. I suggest you to try again, it should work.
I habe a web role in azure. It is running fine locally in development app fabric, but fails silently when deployed to Azure (simply no response at all for any request).
I assume it's some problem with the web.config, but that is happening so early that it occurs already before I can set up the diagnostic stuff in global asax. As said, it's working fine locally, but there is simply no response at all from the azure system.
How can I find out what specifically is wrong to be able to solve it like get the exception text, stack trace, IIS application system error log or anything that could hint me to the real problem?
The absolute first thing that is run in a Web role is not your application but the OnStart() method in WebRole.cs in your Azure project. This is the place to add code to monitor your Web site.
The standard technique is to copy your application trace logs and the Windows event logs to Azure table storage, together (if appropriate) with instrumentation for CPU usage, IIS statistics and what-have-you.
A good introduction to this is here: http://blog.bareweb.eu/2011/01/beginning-azure-diagnostics/
and a good followup with details on the specifics you'll need in your application is here: http://blog.bareweb.eu/2011/03/implementing-azure-diagnostics-with-sdk-v1-4/
which remains applicable for the Azure SDK 1.5.
Once you are capturing diagnostics, you can either use Visual Studio to view them directly, or you can use a tool like the Cerebrata Azure Diagnostics Manager to graph and filter them automatically. This tool is a little rough around the edges (especially for larger systems with multiple instances: the graphs aren't really useful) but is as good as it gets at the moment.
An alternative approach is to use Remote Desktop to connect to the remote instance and do some spelunking in the Windows event logs and suchlike. You can also use the Internet Explorer browser that's on the remote instance to directly connect locally to the application and see any errors etc. that may otherwise be hidden.
Personally I'd only do this if the diagnostic storage mechanism isn't working: production servers really should have remote desktop access turned off altogether to reduce the possible surface area for external attack.
Setting up diagnostics is the best long term solution to dealing with tracking errors in your application. If you want something a little more ad-hoc you can either catch the errors and write them to blob storage or use your own light weight trace listener.