We have a Web application, developed with ASP.Net Core and deployed on Azure using Docker container. The Web App uses serilog library (https://serilog.net/) as internal logging engine. The configuration of Serilog is stored in the file serilog.json, included in the Visual Studio Solution Explorer and, obviously, in the final Docker container.
Using a special admin panel included in the Web App, an administrator can change the active Serilog log level to any supported value (Fatal, Error, Warning and so on). This feature simply updates the file serilog.json, and ASP.NET Core reloads on-the-fly the new log level.
It works like a charm, but now the problems begins.
We use Azure DevOps to deploy every nighty a new version of our Web App, so every night the current Docker container is overwritten with the newest one. Also the file serilog.json, so every night we lose the log level configuration.
What are we wrong with this approach?
We need to move 'serilog.json' outside the Docker container and store it in another location?
Any idea?
Thanks for your help, support and discussion!
Related
I have some app services and I update the web sites content by uploading the data via FTPS.
Occasionally, after I upload new content, the sites don't display it at all or partially until the app service is restarted.
Is this normal behavior?
What can be done to avoid restarting or monitoring the site and automatically restarting the app service if the site does not appear properly after updating the content?
Thanks
Just to highlight, based on your application framework - Unlike Git-based deployments and Zip deployment, FTP deployment doesn't support build automation, such as: dependency restores (such as NuGet, NPM, PIP, and Composer automations), compilation of .NET binaries, generation of web.config (here is a Node.js example).
You may generate these necessary files manually on your local machine, and then deploy them together with your app.
Additionally, App Service deploys files to the wwwroot folder. It never directly restarts your app.
You may verify if the deployment files are in root folder. A deployment issue is an issue that causes the wrong set of files to get deployed to your site folder (typically d:\home\site\wwwroot). Deployment-vs-runtime-issues
Can I host a web application created on .net core 2.1 with sql server as database to azure web app service using CI tools / MS WebDeploy?
The following points I want to take care:
The application is using file system for temp storage and file storage
Deployment should be managed by some CI tools such as jenkins
After deployment, the app settings file should be modified with some keys/server details
Log files(stored on app root) should be accessible by application administrator
Is there a way to create a virtual directory same as in IIS and upload the files using FTP or similar protocols..?
All your doubts about deploying .net core 2.1 web app are achievable.
Suppose our projects are all completed and uploaded to github.
Questions and explanations about your concerns：
About the connection configuration using the database, you can directly configure it in web.config. If you are using azure sql server, find the connection string, set up the firewall, and pass the SSMS test, you can test the connection in the code. It can also be added in the Configuration -> Application settings -> Connection strings in the portal. After the addition, the priority is higher than the configuration in web.config, which will override the configuration and not modify the web.config file.
Regarding the use of file storage, you can use azure storage services or not. Looking specifically at the business, for example, very small pictures, documents and other files can be stored in the current program running directory, which is consistent with the original development at the code level. When publishing, you need to include the MyFiles file in the publishing process, or wait for the publishing to be completed and add folders manually in kudu, or the program can judge. It is recommended to use the program to judge that the subsequent program upgrade will not lose data.
The confidential information in the app settings file can actually be configured in web.config or appsetting.json. Make sure that the offline project is running properly when you are debugging locally, and then you can publish it. The rest is configured in the portal as in the first explanation.
The Log Files file storage can fully achieve the effect you want. It should be enough to set the owner permissions of this app services. For details, please refer to the official documentation.
Virtual directories and virtual applications, I have a better answer in another post here, you can refer to it.
Steps：
First of all, we can create a web app in portal and select .net core 2.1. Create appservices, and click Deployment Center when finished.
Follow the prompts step by step, and wait until the Action in github is completed, and the release is successful.
I have been attempting this for a good chunk of today but still have not found a solution.
I have a built spring boot application in the form of a jar.
I push this to a storage account container as a blob with azurerm_storage_blob
I reference this from a azurerm_app_service in app_settings.WEBSITE_RUN_FROM_PACKAGE using a data.azurerm_storage_account_sas
I see that it has pulled the blob from storage in the app-service but it has exploded it under D:\home\site\wwwroot
I have set site_config.java* (java_version, java_container and java_container_version) but it makes no attempt to start the application
I see there is a site_config.app_command_line but none of the examples I have found set this.
Has anybody gotten a spring boot application in a windows app service running using terraform?
Is there a better way to get the application jar to azure using terraform?
There are various ways to deploy your application to Azure App Service. For your scenario, I recommend not to set WEBSITE_RUN_FROM_PACKAGE and make sure your executable jar is called app.jar and it is dropped to the root of your Web App's content folder (/site/wwwroot).
App Service will automatically take care of setting the appropriate SERVER_PORT environment variable behind the scenes, so that when your Spring Boot application starts, it will start listening to the correct port.
If you need to set parameters, you can always set JAVA_OPTS in the App Service Settings section in the Azure portal and those will travel as environment variables and ultimately used by java.exe upon start.
If you hit any rough edge, feel free to open a ticket in Azure portal and we will be able to assist you better to make sure your app runs well in Azure App Service.
Other popular mechanism to deploy is using Maven:
https://learn.microsoft.com/en-us/azure/java/spring-framework/deploy-spring-boot-java-app-with-maven-plugin
Sometimes in our website which is deployed on Azure web roles, issue comes related to small bugs in javascript and HTML. We go to all instances of webroles and fix these JS and HTML file on machines.
But I was looking into some automated way of doing this, downloading the files to patch from some central location and replace the files in all azure web roles. I am using ASP .net MVC for website.
It is possible to redeploy the website with the patch in the package but we don't want to wait for long deployment time. Please let me know if it is possible via some internal WEB API which replaces the content on all azure web roles.
There are 2 ways to deploy a new webrole:
redeploy
inplace update
The first one is the slowest, meaning new VM's are booted.
With inplace upgrade (https://azure.microsoft.com/en-us/documentation/articles/cloud-services-update-azure-service/)
The new application package is mounted on a new drive (usually F: instead of E:) and the IIS website is swapped to the new drive.
You can try this by going to the old portal and upload a new application package. In just a few seconds/minutes the update is done.
After digging many things on stackoverflow, I crafted my own solution which is creating a topic and subscribing to the topic in code when website starts. When I want to patch the web app then I send a message to Topic to start patching then each machine in the web roles will get notification from topic and start patching themselves. Patching itself is very easy, which is going to a web storage and downloading files from there and replacing files in approot.
When azure maintenance happens this patching may go away, so for this situation I made patching work started at start up of website too.
Cloud service deployment packages tend to be slow since they are basically a recipe on how to build and configure your deployment. The deployment not only puts the recipe out in Azure (so it can be used again if it needs to move your machine), but also follows the recipe to build out a VM for your Cloud Service (WebRoles/WorkerRoles are platform as a service so you don't have to worry about the OS and infrastructure level like you would if you were using the Virtual Machine Azure product but they do still run in VMs on physical hardware).
What you are looking to do is something that will update the recipe (your cloud service package) and your deployment after it is out and running already ... there is no simple way to do that in Cloud Services.
However, yes you could create a startup script that could pull the site files from blob storage or some other centralized location - this would compare to how applications (fiddler for example) look for updates then know how to update and replace themselves. For that sort of feature you will likely need to run code as an elevated user - one nice thing about startup scripts are they can run as an elevated user - so they can do about anything you need done on a machine (but will require you to restart the instance for them to run). Basically you would need to write some code that will allow your site to update itself. This link may help: https://azure.microsoft.com/en-us/documentation/articles/cloud-services-startup-tasks/
If you have the ability to migrate to WebApps and WebJobs, I would recommend looking into that since that compute product solves your problem really well.
Here is a useful answer of the differences between WebApps and Cloud Services: What is the difference between an Azure Web Site and an Azure Web Role
I have a question about Remote Desktop deployment on Azure Cloud Application.
First of all I published my app via visual studio.Everything is working.
Yesterday I connected with remote desktop to my azure app and changed some attributes in my web.config files.
First thing : My cloud app is getting so slowly so I think IIS restart etc. but I don't know why my site is coming slowly ?
Second thing : Today when I enter to my app , I can't see my changes and when I check it via remote desktop all my changed things are roll back. Why ?
Do I have to all my deployment via Visual Studio ?
How is staying my deployment in Azure machines ? This machine is sometimes changing or never change when I delete it ?
Thanks,
This is not the expected way to change the settings. Azure is free to relocate your instance to another VM or restart it in-place and erase all your local changes.
So if you want to do some permanent changes you have to do them locally, build the service package and deploy the new package to Azure. This way Azure will have an updated package and your changes will persist.
If you want to change something frequently you have to use the <ConfigurationSettings> node of the service configuration. Your code will have to query the setting and react accordingly. If you want some activity triggered when the service configuration is changed your code has to handle the RoleEnvironment.Changing event.
You cannot make changes in the VM directly, because these changes are not persisted (as you have already noticed). The VM can be recycled and restored at any moment. So you have to make changes by applying them locally and redeploy the site.