Things You Should Know: Web Apps and Linux

Azure App Service on Linux and Web App for Containers allow you to run your Web App on Linux and Apache. Azure App Service on Linux provides a collection of Microsoft-provided runtime stacks that you can use for your Web App. Web App for Containers makes it possible to use your own Docker container in Azure Container Registry, Docker Hub, or a private registry.

In this post, I will cover both of these offerings. Each topic will indicate which offering(s) it applies to using the following icons.

  Applies to Azure App Service on Linux

  Applies to Web App for Containers

If a topic applies to both, that will be indicated by the presence of both icons.

In this post:
If you need info, check the FAQ.
If your site doesn't start, check the Docker log.
You can discover and download the latest Docker logs using Kudu.
If your container takes a long time to start, increase the start time limit.
The Bash console in Advanced Tools is a different Docker container.
If you're persisting files, only the /home directory is persisted.
You can disable storage persistence with an app setting.
Use the X-ARR-SSL header if you need to force SSL for your site.
You don't need (and should not have) SSL support in your app.
To use SSH, your Docker image needs special sauce.
You can only expose one port to the outside world.
If a feature is missing in the portal, it's not available on Linux.
Don't use df to find your disk space usage.

If you need info, check the FAQ.
 

The FAQ for Azure App Service on Linux and Web App for Containers is a great resource to get your questions answered. Our product team (the folks who build our services) regularly updates the FAQ as new features are added or as they encounter customer questions.

A few of the items in this post are included in the FAQ. In those situations, we will provide information here and also point you to the FAQ.

Back to Top

If your site doesn't start, check the Docker log.

We log useful information into the Docker log that can help you troubleshoot your site when it doesn't start or if it's restarting. We log a lot more than you might be used to seeing in a Docker log, and we will continue to work on making this logging more useful.

You can find the Docker log in the /LogFiles directory. You can access this via the Kudu (Advanced Tools) Bash console, by using an FTP client to access it, or by using our API to download the current logs. (See "You can discover and download the latest Docker logs using Kudu" in this post for info on that.) The naming convention for the Docker log is YYYY_MM_DD_RDxxxxxxxxxxxx_docker.log.

Note that if you try and download the Docker log that is currently in use using an FTP client, you may get an error because of a file lock. In that case, you can download it using our API (see "You can discover and download the latest Docker logs using Kudu" in this post) or you can use "tail" in the console to view it. (Our API gets you the current Docker log, so if you want to review a past log, use the "tail" option.)

To view the Docker log using tail, access the console, switch into the LogFiles directory, and run this command:

tail 2017_09_05_RD*0FA_docker.log

In this example, I'm viewing the Docker log for September 5. Note that I'm also using a wildcard replacement for the machine ID (the RD number) so that I don't have to type all the characters.

Tip: You can pipe the output of tail to a new file in case you want to download it. Simply append "> filename.txt" to the command above.

Back to Top

You can discover and download the latest Docker logs using Kudu.

We have an API that allows you to easily see the current Docker log details (such as the filename, etc.) and also download the current Docker logs in Zip format.

To see details on the current Docker logs in JSON format, you can use this URL:

https://[sitename].scm.azurewebsites.net/api/logs/docker

You can get to this easily by going to Advanced Tools (Kudu) and then appending "/api/logs/docker" to the URL. The output of this will be a JSON response with the most relevant and current Docker logs.

If you want to download the logs shown in the above API in Zip format, append "zip" to the URL. For example:

https://[sitename].scm.azurewebsites.net/api/logs/docker/zip

We will be adding a link to download the logs to the Kudu home page soon so that you don't have to manually browse to the API.

Back to Top

If your container takes a long time to start, increase the start time limit.

When we start your container, we'll wait a while for it to start and initialize. We consider the startup to be successful once the container is running and once we get a response to a ping so that we know it's ready to respond to HTTP traffic. We'll wait 230 seconds for that to happen. If we don't have a successful start within 230 seconds, we'll assume there's a problem and we'll stop the container.

We realize that some containers might need more time than that to start, so we allow you to increase that 230 second wait time up to a limit of 600 seconds. To configure that, add an app setting called WEBSITES_CONTAINER_START_TIME_LIMIT and set it to the number of seconds you would like for us to wait for your container to start (up to a maximum of 600) as shown in the image below.

Back to Top

The Bash console in Advanced Tools is a different Docker container.
 

We offer a Bash console in Advanced Tools (also called "Kudu") that you can use to browse directory structure, etc. It's important to realize that this console is running inside of the Kudu Docker container. This is not the same container that your app is running in, so if you look at files and directories here, they won't reflect your app. The only exception to that is the /home directory. That directory is, by default, mounted from Azure Storage, and it's the same location in both the Kudu container and your app's container.

Back to Top

If you're persisting files, only the /home directory is persisted.

By default, we mount the /home directory to Azure Storage. If your app is restarted, any files saved within the /home directory and sub-directories will persist. However, any files or directories outside of the /home directory will not be persisted between site recycles. This can impact you in a couple of different ways.

• If you use npm, apt, or similar to install something from the console after your app starts, once the app restarts, whatever you installed will be gone.
• If you save files outside of the /home directory, if you app restarts, those files will be gone.

If you need an extension or other component for your app to run, make sure that you install it via your Dockerfile. That way, it will be available always. If you need to persist files that your app is creating, make sure that you write them into the /home directory structure.

For more information on creating your own container for use with Web App for Containers, see our documentation.

Back to Top

You can disable storage persistence with an app setting.

If you don't want the /home folder to be mounted to Azure Storage for file persistence, you can disable storage persistence. Simply add an app setting called WEBSITES_ENABLE_APP_SERVICE_STORAGE and set it to "false" as shown in the image below.

Why do this? The most common reason is because you don't want to incur a site restart if there is a storage changeover. These changeovers do occur from time to time, and when they do, the storage volume that's mounted to /home will change, triggering a site restart. By disabling storage persistence, you can avoid that restart. You'll still have a /home folder, but it won't be mounted to Azure Storage.

Note: If you do this, any files written into the /home folder will not be persisted across instances (in the case of a scale out) or across restarts.

Back to Top

Use the X-ARR-SSL header if you need to force SSL for your site.
 

You can use a .htaccess file to enforce SSL on your site. Many developers already know how to do this, and most techniques rely on checking for an HTTPS request and redirecting the request to HTTPS if it isn't an SSL request. This won't work for Azure App Service on Linux or Web App for Containers because we terminate SSL at the front-end. That means that all of the requests that get to your app container are going to be HTTP (not HTTPS) from our front-end to your app. (Don't worry. Any network traffic that can be intercepted is going to be encrypted if you use SSL.)

The correct way to check for an SSL request is to check the X-ARR-SSL header. We set this if the request comes into our front-end as an SSL request. For details on how to do that, see this blog post.

Back to Top

You don't need (and should not have) SSL support in your app.
 

As pointed out above, we terminate SSL at the front-ends. That means that SSL requests never get to your Web App. That's good news for you because it means that you don't need to (and should not) implement any support for SSL into your app. Also as stated above, it's important to understand that the front-ends where SSL is terminated are inside of our Azure data centers. If you use SSL with your site, your traffic across the Internet will always be safely encrypted.

Back to Top

To use SSH, your Docker image needs special sauce.

We provide the ability to SSH into your app, but if you're using a custom container, you need to take additional steps in order to add this ability to your app. We've provided all the steps necessary here.

Back to Top

You can only expose one port to the outside world.

Web App for Containers currently allows you to expose only one port to the outside world. That means that your container can only listen for HTTP requests on a single port. Some apps need multiple ports. For example, you might have one port that is used for requests into the app and a separate port that is used for a dashboard or admin portal. As of today, that configuration isn't possible in Web App for Containers.

We will attempt to detect which port to bind to your container, but you can also use the WEBSITES_PORT app setting and configure it with a value for the port you want to bind to your container.

Back to Top

If a feature is missing in the portal, it's not available on Linux.
 

Azure App Service has a rich feature-set, but not all of those features are currently available for Linux apps. We're working on adding new features all the time, and once new features are added, they'll appear on the menu in the Azure portal. If you see that a particular feature is missing from the menu for your Linux apps, it's simply because we haven't added that feature yet.

Back to Top

Don't use df to find your disk space usage.
 

You're probably used to using "df" to find out disk space in your volumes. You can certainly do that in Azure App Service on Linux and Web App for Containers, but what you'll see isn't really going to be as helpful as you might think.

Assuming you are persisting files in the /home directory (which is currently the default), you will have a quota based on your pricing tier. However, if you use "df", the disk space you see won't reflect that quota. If you want to find out your disk usage, use Quotas in your Web App's menu, File System Storage in the App Service Plan's menu, or use the REST API to find your usage.

Back to Top