Index des articles

Volet 1 :

• La modularisation & packaging de code Python
• L’intégration sur Azure

Volet 2 (A & B) :

• L’installation du package depuis Artifacts (A)
• Déploiement manuel d’une function app utilisant le package (A)
• Pipeline CI CD pour une function app utilisant le package (B)

Volet 3 :

• L’intégration continue avec le testing
• La génération de documentation automatisée

Contenu

Ce second volet sur le packaging de code Python dans un environnement Azure se concentrera sur l’intégration du package dans le cas d’une Function App, déployée sur une Azure Function.

La partie A couvrira la partie dev : l’installation en local et le déploiement manuel de la function app avec le package
La partie B couvrira la partie prod : la création de pipelines CICD pour déployer la function app en continue, avec le package utilisé pour le développement.

Contexte

Un package Python a été mis à disposition par un membre de votre équipe sur Azure Artifacts et vous est donc accessible. Pour avancer, il vous faut désormais : installer ce package sur votre environnement local puis faire en sorte qu’il soit installé sur l’Azure Function sur laquelle vous travaillez.

Installer le package dans mon environnement de dev

Notre point de départ est Azure Artifacts, qui nous donne l’URI de notre feed.

Cliquez sur « Connect to feed » puis sur « pip ».

Si ce n’est pas déjà fait, il est temps de créer un environnement virtuel, donc retour à notre IDE préféré et on tape les commandes suivantes dans un terminal.

python3 -m venv .env
source .env/bin/activate
pip install --upgrade pip

Intéressons-nous maintenant à l’instruction fournie par MS pour configurer pip. Pour comprendre ce paramètre, il est important d’avoir en tête que pip est l’utilitaire d’installation de nos packages et non la source. La source de ces derniers est PyPI.org. Pip nous permet donc de chercher des packages à d’autres endroits et c’est là que les paramètres –extra-index-url et –index-url sont utiles : ils nous permettent de, respectivement, compléter et remplacer PyPI par un autre index.
Notez que l’on peut utiliser plusieurs –extra-index-url dans une même commande.

Pip va alors scanner les différents index qu’on lui donne, à la recherche de chacun des packages demandés, et les télécharger depuis la source en présentant la version la plus élevée. Comme discuté sur cet intéressant thread, cela peut poser des soucis de sécurité mais il existe des workarounds.

L’interface du feed suggère de configurer pip avec un fichier .ini ou .conf selon l’OS. Si vous ne souhaitez pas toucher aux configurations, vous pouvez simplement utiliser la commande :

pip install tuto-package --extra-index-url=https://pkgs.dev.azure.com/charlesgosselin/_packaging/python_packages/pypi/simple/

Il est nécessaire qu’Artifacts puisse vous identifier afin de vous donner l’accès au feed, pour cela je vous renvoie à mon premier volet où l’on s’authentifie, de la même façon, pour mettre en ligne le package.

Le package est bien installé ! Rappel du code source ici.

Passons maintenant à une application à plus forte valeur ajoutée.

Déployer la Function App manuellement, avec le package

Voici maintenant une méthode permettant de déployer un package absent de PyPI.org sur une Azure Function. L’Azure Function est instanciée ici en mode « code » (par opposition à « Docker Container »), ce qui est plus contraignant car on n’a pas d’interface SSH pour manipuler l’environnement de la Function : les méthodes abordées ici fonctionnent donc a fortiori en mode Docker Container.

Commençons par vérifier notre version de Python, pour cela on ouvre un Azure Shell ou n’importe quel shell, tant que la librairie Az y est installée.

Je travaille pour ce tuto sur une Azure Function dénommée « tuto-package-function » dans le resource group « sandbox ».

Cette vérification est importante car depuis la version 3.7, les packages ne s’installent plus au même endroit.

•  ./.python_packages/lib/python3.6/site-packages (Python 3.6)
• ./.python_packages/lib/site-packages (Python 3.7+)

Note : La seule façon de changer la version Python embarquée dans une Azure Function une fois déployée, est la commande « az webapp config ».

Deux possibilités s’offrent à nous pour déployer la Function App avec le package.

• Installer en local la totalité des packages et déployer la function app en utilisant le paramètre « no-build » ;
• Déployer la function app normalement, en ajoutant la configuration PIP_INDEX_EXTRA_URL

1 – L’installation en local

On ajoute au requirements.txt notre package, puis on place dans un virtual env où sont installés pip et artifacts-keyring et on exécute la commande :

pip install -r requirements.txt --extra-index-url "https://pkgs.dev.azure.com/charlesgosselin/_packaging/python_packages/pypi/simple/" --target=".python_packages/lib/python3.6/site-packages"

Après une rapide authentification, votre function app est désormais prête à être envoyée, tel quel. Vérifiez que vous n’avez pas ajouté votre dossier .python_packages au .funcignore, ce qui l’excluerait du déploiement.

Il ne vous reste qu’à déployer la function, avec l’option –no-build.

func azure functionapp publish tuto-package-function --no-build

Et hop, notre Function App est en ligne et renvoie le résultat attendu !

2 – L’installation en remote

Rendons-nous dans Azure, sur notre Azure Function, dans les configurations.
Il suffit maintenant d’ajouter une configuration nommée PIP_EXTRA_INDEX_URL contenant l’URL mise à disposition dans Artifacts.

En ajoutant cette variable dans les configurations de la function, Oryx, l’utilitaire de build utilisé par Azure Function, comprend qu’il faut ajouter le paramètre –extra-index-url lorsqu’il fait le pip install -r requirements.txt.

Attention, cette option ne vous est permise que si le répertoire de package est accessible publiquement. En effet, l’authentification interactive qu’on utilise jusqu’ici, faisant appel à artifacts-keyring, n’est pas possible tel qu’Oryx est implémenté.

L’utilitaire n’affichant pas les logs, il ne nous est pas possible de récupérer le code à insérer sur microsoft.com/devicelogin et l’utilitaire freeze à cet étape, jusqu’à timeout.

Merci d’avoir lu cet article et on se retrouve dans la partie B pour industrialiser ce processus.