Les images de conteneur personnalisées permettent de déployer des fonctions sous forme d'images de conteneur dans Function Compute. Elles facilitent la migration à moindre coût, la mise en cache par couches et l'intégration CI/CD.
Avantages
Function Compute prend en charge les images de conteneur personnalisées comme artefacts de fonction :
Migration économique sans modification du code ni recompilation binaire. Les fichiers d'objets partagés (*.so) garantissent la cohérence entre les environnements de développement et de production.
Simplifiez la distribution et le déploiement en regroupant le code et ses dépendances.
Accélérez le chargement et le téléchargement du code grâce à la mise en cache par couches.
Exploitez des outils CI/CD open source pour standardiser la construction, le partage et le versionnage des bibliothèques tierces et du code.
Interagissez avec Function Compute via HTTP.
Exécutez des images non interactives.
Fonctionnement
Avant d'initialiser une instance, Function Compute endosse le rôle de service de la fonction pour obtenir un nom d'utilisateur et un mot de passe temporaires afin de récupérer l'image. Une fois l'image téléchargée, le conteneur démarre avec les paramètres Command et Args spécifiés.
L'image de conteneur doit intégrer un serveur HTTP. Function Compute se connecte à votre serveur HTTP personnalisé sur le port CAPort configuré. Ce serveur traite toutes les requêtes adressées à Function Compute, y compris les invocations API et HTTP. Vous pouvez invoquer une fonction de deux manières :
Par appel API

Par requête HTTP

Limites
Taille maximale de l'image
Pour ACR Personal Edition ou Enterprise Edition (Basic, Standard ou Premium), la taille maximale non compressée est de 10 Go pour les instances CPU et de 15 Go pour les instances accélérées par GPU.
Dépôt d'images
Function Compute accepte les images provenant des dépôts Container Registry Personal Edition et Enterprise Edition.
ACR Economy Edition ne prend pas en charge l'accélération d'images et n'est pas compatible avec Function Compute. Utilisez des images issues d'instances ACR Personal Edition ou Enterprise Edition (Basic, Standard ou Premium).
Accès aux images
Seules les images publiques d'ACR Personal Edition sont accessibles entre comptes dans la même région. Toutes les autres images sont restreintes aux dépôts privés du même compte et de la même région.
Permissions de lecture et d'écriture dans les conteneurs
Par défaut, les conteneurs s'exécutent en tant que root (UID=0). Si un utilisateur est défini dans le Dockerfile, le conteneur s'exécute sous cet utilisateur.
Limite de stockage de la couche inscriptible des conteneurs
La couche inscriptible du conteneur est limitée à 512 Mo ou 10 Go, selon la taille du disque définie dans la configuration avancée de la fonction. Créer une fonction.
Les données de la couche inscriptible ne sont pas persistantes et sont supprimées lors de la destruction du conteneur. Pour un stockage persistant, montez un système de fichiers NAS ou un bucket OSS dans Function Compute. Configurer un système de fichiers NAS. Configurer Object Storage Service. D'autres services de stockage partagé, tels que Tablestore, sont également pris en charge.
Architecture d'image prise en charge
Function Compute prend uniquement en charge les images AMD64. Sur les machines basées sur ARM (comme les Mac équipés de puces Apple), spécifiez la plateforme de build linux/amd64. Exemple de commande : docker build --platform linux/amd64 -t $IMAGE_NAME ..
Exécutez docker inspect pour vérifier l'architecture. Si la sortie contient "Architecture" : "amd64", l'image est correcte.
Prérequis du serveur HTTP
Les exigences suivantes s'appliquent aux fonctions utilisant un conteneur personnalisé avec serveur web :
-
Le serveur HTTP doit écouter sur
0.0.0.0:CAPortou*:CAPort. Si le service écoute sur127.0.0.1:CAPort, les requêtes expirent et l'erreur suivante se produit :{ "ErrorCode":"FunctionNotStarted", "ErrorMessage":"TheCA'shttpservercannotbestarted:ContainerStartDuration:25000000000.PingCAfaileddueto:dialtcp21.0.XX.XX:9000:getsockopt:connectionrefusedLogs:2019-11-29T09:53:30.859837462ZListeningonport9000" }Le port d'écoute par défaut est 9000, configuré via la propriété
CAPort. Votre serveur HTTP doit impérativement écouter sur ce même port. -
Le serveur doit prendre en charge
Connection: Keep-Aliveavec un délai d'expiration des requêtes d'au moins 15 minutes :// For example, when using Express in Node.js. var server = app.listen(PORT, HOST); server.timeout = 0; // never timeout server.keepAliveTimeout = 0; // keepalive, never timeout Le serveur HTTP doit démarrer en moins de 120 secondes.
En-têtes de requête courants
Les images de conteneur personnalisées utilisent les mêmes en-têtes de requête que les runtimes personnalisés. En-têtes de requête courants dans Function Compute.
Format des journaux
Simple Log Service collecte automatiquement tous les journaux stdout des images de conteneur personnalisées dans le projet spécifié. Configurer la fonctionnalité de journalisation.
Le format des journaux pour les images de conteneur personnalisées est identique à celui des runtimes personnalisés. Format des journaux de fonction.
Optimisation du démarrage à froid
Le téléchargement et la décompression des images de conteneur prennent plus de temps que ceux des packages de code. Pour réduire la latence de démarrage à froid :
Utilisez une adresse d'image VPC située dans la même région que Function Compute afin de diminuer la latence de récupération et d'améliorer la stabilité.
Minimisez la taille de l'image. Optez pour une image de base légère comme Alpine ou Ubuntu, et n'incluez que les dépendances strictement nécessaires.
Maintenez les conteneurs actifs grâce aux instances provisionnées. Configurer une politique d'élasticité du nombre minimal d'instances.
Si vos ressources le permettent et que vos fonctions sont thread-safe, activez la concurrence par instance unique pour limiter les démarrages à froid et maîtriser les coûts. Créer une fonction web.
Facturation
Les images de conteneur personnalisées suivent le même modèle de facturation que les autres runtimes. Vue d'ensemble de la facturation.
Le temps de récupération de l'image est inclus dans l'utilisation des ressources, calculé du début à la fin du téléchargement. Par exemple, une instance de 1 024 Mo nécessitant 10 secondes pour récupérer une image consomme 10 Go-secondes.
Les images étant mises en cache pendant une certaine durée, les frais de récupération ne s'appliquent pas à chaque démarrage à froid.