Pour plus de commodité, j'ai touché au PaaS basé sur Cloud Foundry (Diego), j'ai donc essayé de déployer l'application à l'aide de Flask, que j'utilise habituellement. Comme c'était la première fois que je touchais sérieusement à CF, il y avait des points qui ont été pris, donc je vais le décrire comme un simple point. J'espère qu'il sera utile pour ceux qui sont nouveaux sur le PaaS et qui veulent l'utiliser mais ne le connaissent pas.
Si vous connaissez la mucoviscidose, dites-moi différentes choses, comme signaler les erreurs ...!
J'ai mis l'exemple de code ci-dessous. Pour ceux qui sont nouveaux dans les applications CF, commentez-le.
J'essaie d'utiliser Enterprise Cloud PaaS de NTT Communications où Diego de Cloud Foundry est déployé. Il semble que Diego ait déjà déployé Pivotal Web Service, donc je pense que cela fonctionnera.
cf version 6.14.0+2654a47-2015-11-18
--Cadre utilisé
--Flask (Aucune version spécifiée, laissez-le à pip du côté PaaS)Tout d'abord, installez et définissez cf_cli pour utiliser Cloud Foundry. Je pense qu'il est rapide de voir Officiel ici, mais Max OS 64 bits, Windows 64 bits, Le paquet pour Linux 64 bits est distribué [^ 1], il suffit donc de le télécharger et de l'ouvrir.
[^ 1]: En écrivant cet article, j'ai appris que Mac pouvait aussi être fait avec Homebrew ...
Après l'installation, connectez-vous avec la commande cf.
cf login [-a API_URL] [-u USERNAME] [-p PASSWORD] [-o ORG] [-s SPACE]
Ceci est défini à l'aide des informations de compte fournies par le fournisseur de services. L'espace et l'organisation peuvent être omis s'il n'y en a qu'un.
Si vous vous connectez avec succès, les informations suivantes seront renvoyées.
API endpoint: https://paas-uk1-ecl.api.ntt.com (API version: 2.47.0)
User: ecid1*********0@econ1*********1
Org: econ1*********1
Space: demonstration
Une fois connecté, par défaut ~ / .cf / config.json
est créé et enregistré dans votre répertoire personnel. Cela peut être déplacé avec la variable d'environnement CF_HOME
.
Obtenez la liste des utilisateurs et vérifiez-la au cas où vous seriez connecté.
$ cf org-users econ1*********1 -a
Getting users in org econ1*********1 as 2*****************P8****nV...
USERS
2*****************P8****nV
Obtenez le code de git
$ git clone [email protected]:yuta-hono/flask-cloudfoundry-sample.git
Exécutez cf push
dans le répertoire correspondant. Cela se déploiera sur CF avec le répertoire actuel sous forme d'application. Cette fois, le pack de construction Python est appelé à partir de l'URL externe et du pack de construction de la communauté CF avec l'option -b
.
$ cf push <nom de l'application> -b https://github.com/cloudfoundry/python-buildpack
Après un certain temps, la construction sera terminée et le résultat suivant sera renvoyé. Si vous courez, vous réussissez!
requested state: started
instances: 1/1
usage: 128M x 1 instances
urls: <yourapp>.uk1.eclpaas.com
last uploaded: Tue May 23 10:50:05 UTC 2016
stack: cflinuxfs2
buildpack: python_buildpack
state since cpu memory disk details
#0 running 2016-05-24 10:50:52 PM 0.0% 18.8M of 128M 147.6M of 256M
Presque Original CF Document pose des questions et des solutions que vous souhaitez mettre votre application sur PaaS mais ne savez pas quoi chercher. -deploy.html # "Prepare to Deploy"), mais je l'ai mis ensemble dans l'exemple de code ci-dessus. Je n'ai pas tout mis en œuvre, mais j'ai résumé les parties de base en code simple, donc je pense que ce sera plus facile à comprendre si vous le lisez en regardant l'exemple de code.
Dans CF, le port de déploiement est attribué dynamiquement dans Container. Il est possible de voir le port et l'adresse IP attribués, mais le port et l'adresse IP peuvent être modifiés dans ce cas, car l'application sera redémarrée en cas de redéploiement ou de défaillance d'une autre infrastructure ou d'un conteneur. En d'autres termes, il ne peut pas être décrit en statique.
CF est une [variable d'environnement] appelée PORT
à l'intérieur du conteneur où l'application est déployée (http://docs.cloudfoundry.org/devguide/deploy-apps/environment-variable.html#PORT" Variables d'environnement de Cloud Foundry
Cela rend ") plus facile, vous devez donc le définir dynamiquement comme port d'application.
Dans l'exemple de code, il est écrit comme suit. (Extrait de hello.py
)
hello.py
import os
~snip~
cf_port = int(os.getenv("PORT"))
~snip~
app.run(port=cf_port)
Pour référence, si vous essayez de déployer l'exemple de code sur CF, vous pouvez consulter la liste des variables d'environnement du conteneur de destination de déploiement sur http: // <yourapp> / vars
, il est donc facile à comprendre si vous vérifiez les variables d'environnement fournies par CF. Je pense.
Le journal d'application peut être obtenu en sortant vers la sortie standard «STDOUT» ou la sortie d'erreur standard «STDERR». (Assurez-vous que la sortie vers [http://docs.cloudfoundry.org/devguide/deploy-apps/streaming-logs.html#app) semble être la clé) Dans CF, il y a une fonction pour suivre les journaux d'application en fonctionnement, et vous pouvez utiliser cette fonction pour vous connecter. Cela peut être confirmé.
$ cf logs blue
Connected, tailing logs for app blue in org econ1*********1 / space demonstration as 2*1...
2016-05-24T22:51:21.02+0900 [RTR/0] OUT demonstration.uk1.eclpaas.com - [24/05/2016:13:51:21 +0000] "GET / HTTP/1.1" 200 0 12 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36" 10.0.0.7:35858 x_forwarded_for:"192.168.0.43, 10.0.0.7" x_forwarded_proto:"http" vcap_request_id:8d5086b2-9ffd-4901-4ce5-80bcef39557c response_time:0.005617514 app_id:ae1b5d8f-2159-4259-947e-c4b01e1cd513
2016-05-24T22:51:21.02+0900 [APP/0] ERR 10.0.50.151 - - [24/May/2016 13:51:21] "GET / HTTP/1.1" 200 -
Il existe plusieurs types de journaux, le type APP est le type d'application et les autres sont des journaux fournis par CF. Pour plus d'informations, consultez Journalisation des applications dans Cloud Foundry.
Il semble qu'il soit nécessaire de considérer un peu plus lors de son fonctionnement, mais je voudrais le résumer séparément s'il y a une opportunité.
Cela ne semble pas être une fonctionnalité native de CF. Il semble que certains fournisseurs de services qui fournissent CF implémentent leur propre planificateur de tâches en tant que module externe, mais selon Pivotal, un grand développeur de CF, [Si vous n'avez pas Cron, vous pouvez exécuter le travail en tant qu'application. Pas bon](https://blog.pivotal.io/labs/labs/scheduling-tasks-on-cloud-foundry "Planification des tâches sur Cloud Foundry" ") (Beaucoup de traduction).
pouvez.
Dans l'exemple de code, .profile.d
est le répertoire pour cela.
En plaçant un script shell avec l'extension .sh
dans ce répertoire, ce script sera exécuté côté CF au moment du déploiement, vous l'utiliserez donc pour définir les variables d'environnement.
Par exemple, dans cet exemple de code, MY_OWN_ENV_VAR
est défini, sinon il existe des variables d'environnement fournies par CF.
Pour référence, dans le cas de l'exemple d'application de code, vous pouvez voir qu'il peut être défini sur http: // <yourapp> / vars
.
Alternativement, vous pouvez vous connecter au conteneur où l'application est déployée avec $ cf ssh <yourapp>
, donc après vous être connecté, vous pouvez vérifier la liste des variables d'environnement avec $ printenv
.
** Est inutile. ** ** Dans l'environnement CF, les données placées à l'intérieur du conteneur dans lequel l'application est déployée sont volatiles à l'exception des données incluses au moment du déploiement. Par conséquent, il disparaît facilement lorsque l'application est redémarrée dans un autre conteneur. Les données persistantes utiliseront le stockage externe. Les statiques utiliseront le stockage d'objets s3 et d'autres types de stockage, et les données utiliseront probablement un service RDB externe. Selon le fournisseur, il existe également des endroits où cela est intégré et fourni, veuillez donc vérifier avant d'utiliser.
J'omettrai la méthode d'utilisation spécifique car elle sera un peu plus compliquée que l'exemple de code, mais Bind and use services, Il semble que vous puissiez le faire facilement.
Vous voulez ignorer README.md et .git et ci-dessous. Dans un tel cas, utilisez «.cfignore».
C'est presque le même mécanisme que .gitignore
.
Par défaut, il ignorera les fichiers et répertoires suivants (https://docs.cloudfoundry.org/devguide/deploy-apps/prepare-to-deploy.html#exclude).
.cfignore
_darcs
.DS_Store
.git
.gitignore
.hg
/manifest.yml
.svn
L'exemple de code est défini pour ignorer «README.md» et «LICENSE».
Par exemple, si vous essayez cf ssh <app_name>
dans l'application déployée,
vcap@gisruph1uo0:~$ ls
app logs staging_info.yml tmp
Ça ressemble à ça. ʻApp` Il y a une application déployée à l'intérieur, alors jetons un coup d'œil.
vcap@gisruph1uo0:~$ cd app
vcap@gisruph1uo0:~/app$ ls
hello.py Procfile requirements.txt runtime.txt templates
Il est correctement ignoré. Vous pouvez essayer l'effet en éditant .cfignore
, veuillez donc l'utiliser.
En termes de réseau, il sera écouté "0.0.0.0 / 0". De plus, le port de liaison de l'application elle-même sera écouté «0.0.0.0 / 0». Les restrictions d'accès au réseau sont donc (presque) indisponibles.
Cependant, puisque le côté CF place l'adresse IP du client dans l'en-tête de requête HTTP appelé «X-Forwarded-For», il est possible de restreindre l'accès par l'IP source du côté application en l'utilisant. (X-Forwarded-For
est familier dans ELB d'AWS etc.)
Dans l'exemple de code, cela se fait comme suit. (Extraire / modifier uniquement la partie pertinente)
from flask import request
srcIp = request.access_route[0]
# List of IP addresses to allow the access
allowed_ip = ['192.0.2.1', '192.0.2.2']
@app.route('/ip')
def showIp():
if srcIp not in allowed_ip:
abort(403)
return 'Your IP %s is allowed' % srcIp
Je peux obtenir X-Forwarded-For avec flask.request.access_route
, mais Flask stocke la valeur ajoutée à X-Forwarded-For sous forme de tableau. Le ʻaccess_route [0] spécifié ici est le premier lorsque la valeur de
X-Forwarded-For est
192.0.2.1, 192.0.2.2, c'est-à-dire
192.0.2.1`. Cela vous fera ressentir.
En termes de CF, l'adresse IP source du client n'est placée que dans X-Forwarded-For
, mais selon le fournisseur, un équilibreur de charge, etc. peut être pris en sandwich à l'avant et plusieurs valeurs peuvent être stockées, donc Un ajustement est nécessaire selon le cas.
Dans l'exemple de code, la restriction d'accès par IP source du client est implémentée sur http: // <yourapp> / ip
. Vous pouvez changer l'adresse IP autorisée en changeant la liste de ʻallowed_ip`, alors essayez-le.
Dans l'exemple de code, par souci de simplicité, une méthode est définie pour la ressource / ip
pour déterminer l'autorisation d'accès, mais dans le cas de Flask, le comportement avant d'accepter la demande est défini dans le décorateur pour before_request
. Oui, vous pouvez simplement restreindre l'accès à toutes les pages.
Voir Flask Official Documentation, API Chapter pour plus d'informations.
Dans l'exemple d'environnement de code, vous pouvez voir l'en-tête de la requête HTTP en bas de l'écran à http: // <yourapp> / vars
.
Cette fois, j'ai essayé de mettre en place le processus de déploiement et d'exécution de l'application sur CF pour le moment. En ce qui concerne la phase d'exploitation (déploiement, collecte de journaux, surveillance, etc.), je pense qu'il y aura encore beaucoup de problèmes, mais comme ce sera long, j'aimerais le résumer dans un autre article s'il y a une opportunité.
Recommended Posts