Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://learn.microsoft.com/en-us/azure/app-service/faq-app-service-linux below:

App Service on Linux FAQ

These commands or scripts are executed after the built-in Docker container is started, but before your application code is started.

This action is the same as a Docker restart.

Yes, you can do that through the source control management (SCM) site.

Note

You can also connect to the app container directly from your local development machine using SSH, SFTP, or Visual Studio Code (for live debugging Node.js apps). For more information, see Remote debugging and SSH in App Service on Linux.

Set the reserved field of the app service to true.

Yes, to set up continuous integration/deployment for Azure Container Registry or DockerHub, by following Continuous Deployment with Web App for Containers. For private registries, you can refresh the container by stopping and then starting your web app. Or you can change or add a dummy application setting to force a refresh of your container.

Yes.

Yes, you need to set an app setting called WEBSITE_WEBDEPLOY_USE_SCM to false.

If Git deployment fails to your Linux web app, choose one of the following options to deploy your application code:

• Use the Continuous Delivery (Preview) feature: You can store your app's source code in an Azure DevOps Git repo or GitHub repo to use Azure Continuous Delivery. For more information, see How to configure Continuous Delivery for Linux web app.

• Use the ZIP deploy API: To use this API, SSH into your web app and go to the folder where you want to deploy your code. Run the following code:

  curl -X POST -u <user> --data-binary @<zipfile> https://{your-sitename}.scm.azurewebsites.net/api/zipdeploy
  

  If you get an error that the curl command isn't found, make sure you install curl by using apt-get install curl before you run the previous curl command.

Yes, disable perMessageDeflate in your server-side Node.js code. For example, if you're using socket.io, use the following code:

const io = require('socket.io')(server,{
  perMessageDeflate :false
});

Yes.

Yes, during a Git deployment, Kudu should detect that you're deploying a PHP application (thanks to the presence of a composer.lock file), and Kudu will then trigger a composer install.

Yes, this functionality is available from the Azure CLI. You can use system-assigned or user-assigned identities. This functionality isn't currently supported in the Azure portal.

If WEBSITES_ENABLE_APP_SERVICE_STORAGE setting is unspecified or set to false, the /home/ directory won't be shared across scale instances, and files written won't persist across restarts. Explicitly setting WEBSITES_ENABLE_APP_SERVICE_STORAGE to true enables the mount. Once this is set to true, if you wish to disable the mount, you need to explicitly set WEBSITES_ENABLE_APP_SERVICE_STORAGE to false.

App Service on Linux uses two different types of storage:

• File system storage: The file system storage is included in the App Service plan quota. It's used when files are saved to the persistent storage that's rooted in the /home directory.
• Host disk space: The host disk space is used to store container images. It's managed by the platform through the docker storage driver.

The host disk space is separate from the file system storage quota. It's not expandable and there is a 15-GB limit for each instance. It's used to store any custom images on the worker. You might be able to use larger than 15 GBs depending on the exact availability of host disk space, but this isn't guaranteed.

If the container's writable layer saves data outside of the /home directory or a mounted azure storage path, the host disk space will also be consumed.

The platform routinely cleans the host disk space to remove unused containers. If the container writes a large quantity of data outside of the /home directory or Bring Your Own Storage (BYOS), it results in startup failures or runtime exceptions once the host disk space limit is exceeded.

We recommend that you keep your container images as small as possible and write data to the persistent storage or BYOS when running on Linux App Service. If not possible, you have to split the App Service plan because the host disk space is fixed and shared between all containers in the App Service Plan.

You can configure the amount of time the platform waits before restarting the container. To do so, set the WEBSITES_CONTAINER_START_TIME_LIMIT app setting to the value you want. The default value is 230 seconds, and the maximum value is 1800 seconds.

Provide the full registry URL, including https://.

Add the full image name, including the private registry URL (for example, myacr.azurecr.io/dotnet:latest). Image names that use a custom port can't be entered through the portal. To set docker-custom-image-name, use the az command-line tool.

We don't support exposing more than one port.

Yes, bring your own storage is in preview.

The SCM site runs in a separate container. You can't check the file system or running processes of the app container.

No, the platform handles HTTPS termination at the shared front ends.

Yes, this is required for custom containers. To manually configure a custom port, use the EXPOSE instruction in the Dockerfile and the app setting, WEBSITES_PORT, with a port value to bind on the container.

Yes, overwrite the environmental variable before .NET core app starts. E.g., In the init.sh script: export ASPNETCORE_URLS={Your value}

In order to use ACR with multi-container, all container images need to be hosted on the same ACR registry server. Once they are on the same registry server, you'll need to create application settings and then update the Docker Compose configuration file to include the ACR image name.

Create the following application settings:

• DOCKER_REGISTRY_SERVER_USERNAME
• DOCKER_REGISTRY_SERVER_URL (full URL, ex: https://<server-name>.azurecr.io)
• DOCKER_REGISTRY_SERVER_PASSWORD (enable admin access in ACR settings)

Within the configuration file, reference your ACR image like the following example:

image: <server-name>.azurecr.io/<image-name>:<tag>

• Only one container can be open for access
• Only port 80 and 8080 is accessible (exposed ports)

Here are the rules for determining which container is accessible - in the order of precedence:

• Application setting WEBSITES_WEB_CONTAINER_NAME set to the container name
• The first container to define port 80 or 8080
• If neither of the above is true, the first container defined in the file will be accessible (exposed)

The depends_on option is unsupported on App Service and is ignored. Just as the control startup and shutdown recommendation from Docker, App Service Multi-container apps should check dependencies through application code - both at startup and disconnection. The example code below shows a Python app checking to see if a Redis container is running.

import time
import redis
from flask import Flask
app = Flask(__name__)
cache = redis.Redis(host='redis', port=6379)
def get_hit_count():
    retries = 5
    while True:
        try:
            return cache.incr('hits')
        except redis.exceptions.ConnectionError as exc:
            if retries == 0:
                raise exc
            retries -= 1
            time.sleep(0.5)
@app.route('/')
def hello():
    count = get_hit_count()
    return 'Hello from Azure App Service team! I have been seen {} times.\n'.format(count)
if __name__ == "__main__":
    app.run(host="0.0.0.0", port=80, debug=True)

Web Sockets are supported on Linux apps. The webSocketsEnabled ARM setting doesn't apply to Linux apps since Web Sockets are always enabled for Linux.

Important

Web Sockets are now supported for Linux apps on Free App Service plans. We support up to five web socket connections on Free App Service plans. Exceeding this limit results in an HTTP 429 (Too Many Requests) response.

Pricing varies by SKU and region but you can see more details at our pricing page: App Service Pricing.

When Azure App Services starts your container, the warmup request sends an HTTP request to the /robots933456.txt endpoint of your application. This is simply a dummy endpoint, but your application must reply by returning any status code (including 5xx). If your application logic doesn't reply by sending an HTTP status code to nonexistent endpoints, the warmup request can't receive a response. Therefore, it perpetually restarts your container.

To change from the default behavior, you can customize the warmup endpoint path and status codes that consider the site to be warmed up. To do this, set the WEBSITE_WARMUP_PATH and WEBSITE_WARMUP_STATUSES application settings.

The warmup request also might fail because of port misconfiguration.

To make sure that the port is correctly configured on Azure App Services, see the question, How do I specify the port in my Linux container?

The warmup request by default fails after waiting 240 seconds for a reply from the container. You may increase the container warmup request time-out by adding the application setting WEBSITES_CONTAINER_START_TIME_LIMIT with a value between 240 and 1800 seconds.

The file system of your application is a mounted network share. This enables scale out scenarios where your code needs to be executed across multiple hosts. Unfortunately this blocks the use of file-based database providers like SQLite since it's not possible to acquire exclusive locks on the database file. We recommend a managed database service: Azure SQL, Azure Database for MySQL or Azure Database for PostgreSQL

You can use only letters (A-Z, a-z), numbers (0-9), and the underscore character (_) for application settings.

You can submit your idea at the Web Apps feedback forum. Add "[Linux]" to the title of your idea.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4