I've worked with deployment manager at small scale before.
However, things are getting bigger and I want to switch from Jinja templates to Python.
I was wondering if it is also possible to define the main config.yaml also as python and not only the templates.
Hoped to see something in the official samples.
I read the guide for deployment manager at scale where it looks like this is only for using python files and not YAML's.
But unfortunately the links to GitHub are ending up in 404's.
The following makes me think the main file could be a python file:
gcloud deployment-manager deployments create hierarchy-org-example-dev
--template env_demo_project.py --properties=envName:dev
gcloud deployment-manager deployments create hierarchy-org-example-test
--template env_demo_project.py --properties=envName:test
gcloud deployment-manager deployments create hierarchy-org-example-prod
--template env_demo_project.py --properties=envName:prod
Does anyone know, where to find these configuration_hierarchy samples did go.. or can anyone provide me with another example?
You can't have you main file in Python - it has to be YAML:
A configuration file defines all the Google Cloud Platform resources that make up a deployment. You must have a configuration file to create a deployment. A configuration file must be written in YAML syntax.
However - as you notices - your template files can be in Python:
Templates can be written in either Jinja 2.10.x or Python 3.x. Jinja maps more closely to the YAML syntax, so it might be easier to write templates in Jinja if you are more familiar with YAML.
Related
With App Engine Python27(standard env), it was possible to create a webapp that only serves static resources from the app.yaml. Without writing any Python script.
With Python37 (standard env), I see that it's still possible to have the static_dir in the handlers section of app.yaml but I'm wondering if this will work the same way. Cause I don't define any entrypoint, I don't set a webserver. I have only the app.yaml at the moment.
And the first that blocks me at the moment: if doing so, how do I locally run this app ? (no Python script so no python main.py and dev_appserver.py does not work for Python37).
Thanks for your answers
Yes, the static_dir and static_file configurations work the same way, their sections in the app.yaml reference docs for 2.7 and 3.7 are identical except for the references to the 2.7-specific application_readable option.
Since serving the static content on GAE is identical (the static content is uploaded and served separately from the application code - equivalent, if you want, to serving from a CDN) it doesn't really matter if you're using the 2.7 runtime or the 3.7 one - you're not actually executing any python code, right?
So one option would be to just use 2.7 instead (adding a minimal app skeleton to keep the runtime happy, say by just returning 404 or redirecting to one of the static pages - you can get it from the Quickstart). You can then continue to use the 2.7 development server for local execution.
Another option would be to use 2.7 (as in option 1) just for local development, but switch back to 3.7 for deployment (i.e. update the app.yaml file, drop the skeleton app code or update it for 3.7). A bit more tedious and brittle, but it can be done.
A 3rd option would be to try the updated development server which has some limited support for 3.7, see Python 3.7 Local Development Server Options for new app engine apps. Serving static content might be included in that limited support. You'd need to meet its specific requirements. You'd also need a 3.7-compatible skeleton app, you can get one from the 3.7 Quickstart.
Finally, you could also use some other tool locally during development, if you have one (same advice as for running an actual app locally). It could simply be your browser for static-only content :) Again, the goal is to just develop your static content, GAE will serve it the same way. You won't need any skeleton app in this case.
Side note: I saw this in the Node.js standard env app.yaml reference, not sure if it's applicable to python 3.7 as well, just be aware of it:
In order to use static handlers, at least one of your handlers must
contain the line script: auto to deploy successfully.
I have been experimenting with the Python Cloud Functions. One of my cloud functions utlizies a large text file, that I would love to bundle with my .py file when I deploy it. THe docs are kinda limited on stuff like this..
https://cloud.google.com/functions/docs/quickstart
I was looking, would I just include that file, and a requirements file in my same directory as my function to deploy it. Or do I have to some how require it in my code?
Also, is there any information on how to use a database trigger instead of a http trigger? I was trying to think if the reason my file didn't seem to get included was because I had the wrong way of defining the trigger. How would you create an OnCreate.. or something like that
gcloud beta functions deploy hello_get --runtime python37 --trigger-http
When you deploy your function using gcloud, your project directory is zipped and uploaded. Any files contained in the current directory (and child directories) will be uploaded as well, which includes static assets like your large text file.
Just make sure your text file is in your project directory (or one of the child directories), then use a relative reference to your file in your Python code. It should just work.
I'm trying to validate my AWS keys for S3 storage for my Django project. So I've found this tutorial from the offical site. It shows various Python code but it doesn't say where to write it? What file do I put this code in?
Common practice is to have a system configuration file that lives outside of version control, and then import it into settings.py or your equivalent thereof.
I'm trying to run a hobby project on bluemix that is a combination of nodejs and python, that expects the runtimes to be collocated.
At first, I didn't even know there was a python dependency. So I deployed based on the node SDK starter app.
There is a "requirements.txt" for python dependencies, but I can see it's not really being used. Is there something I can do to get deployment to recognize that the app is a hybrid like this, IOW to process the requirements.txt so when python is invoked my deps are there?
In general, I would recommend splitting the application up so they do not have this dependency. But if you can't, I can think of two options:
Use multi-buildpack. Create the .buildpacks file in the application root directory and push your application with -b https://github.com/ddollar/heroku-buildpack-multi.git option. During staging, the buildpacks specified in that file will be called on your application.
Write your own custom buildpack. It's not that difficult and you can only do the minimum your application needs.
Following up on my last year's question on documentation, I now want to get started and try out Python-based Sphinx for putting together the developer documentation for a PHP CMS I've been working on.
Instead of setting up Python locally on my workstation, I would like to run it on a publicly accessible web server from the start. All the web hosting packages I have access to run on the LAMP stack, and I'm reluctant to buy Python-based hosting. I am very interested in the Google App Engine, the free quotas they provide will do for me a hundred times over, and even if not, their pricing looks very reasonable.
Now I have zero knowledge of Python - getting Sphinx to work would be my first contact with it - and very little time. As far as I understand, the platform and python libraries the App Engine provides are very compatible to a standard Python library but not identical.
So my question is:
Can Sphinx run on App Engine at all?
Is installing Sphinx on the App Engine as straightforward as if I would install it on top of a normal Python installation? Or will the App Engine's environment require tweaking of the source code that I can't perform in reasonable time with my current level of Python?
Should I be installing Sphinx on a local server and a "normal" Python stack instead first?
Does anybody know any helpful How-to's, tutorials or other resources for this?
You do not need to install Sphinx on GAE at all.
You use Sphinx to create a directory of static HTML, CSS and JS. When this step is finished, you simply upload the output from Sphinx -- in it's entirety.
The output from Sphinx (HTML, CSS and JS) is simply served from one place. You upload the documentation from where you created it to GAE as static files and serve them. Done.
There's no "install on a web server" aspect to Sphinx at all. Sphinx is not a web application; it does not run on your web server. You run it in development briefly to publish the documentation to HTML, LaTeX or whatever. Once you've created the static HTML files, you no longer need any part of Sphinx anywhere.
Can Sphinx run on App Engine at all?
I suppose it can, but you never need to.
Is installing Sphinx on the App Engine
as straightforward as...
It doesn't matter, because you don't install it there. You install it on your workstation and use it on your workstation.
Should I be installing Sphinx on a
local server and a "normal" Python
stack instead first?
Don't install it on a server. Install it on your workstation.
Does anybody know any helpful
How-to's, tutorials or other resources
for this?
If by "this" you mean "installing on a web server", then then answer is "no". One does not install it on a web server. So there are no how-to's, tutorials or resources for "installing on a web server".
If by "this" you mean "creating documentation with Sphinx", then the answer is "what's wrong with https://www.sphinx-doc.org? What do they lack?
I would like Sphinx's "engine" that
turns the input (consisting of reST
files) into HTML/CSS/JS to be
accessible from anywhere to make me
(and possible other contributors)
independent from a specific
workstation.
Sphinx is like a compiler. Everyone has their own copy on their workstation. They download the document source, make changes, commit the source changes, and upload the resulting document.
serve the generated documentation from
the same place.
Correct. After you download the source, make changes, regenerate the document and commit the changes, you upload the resulting document so it will be served from one -- and only one -- place.
Sphinx is a compiler. It is not a "web engine". It's a simple compiler that simply compiles your documentation into HTML so it can be served.
Interesting project! The main issue you're going to run into is that of filesystem access: The filesystem on App Engine is read-only, and based on looking at the source, Sphinx is fairly hard-coded to use the filesystem for output. It also expects to read the configuration file and input files from the local filesystem, which would make building docs for anything other than projects bundled with the app tricky.
It is possible to work around this, but it would require writing a simple virtual filesystem that uses the App Engine datastore, and using monkeypatching to make it work with the regular Python file interface. That's rather advanced for a "new to Python" project!
One other thing you might want to consider if you were pondering allowing users to upload projects to be documented: The Sphinx configuration file is in Python, so executing it could be dangerous - a user could do nasty things to your app with a malicious configuration file!
The difference between deployment locally via dev_appserver and remotely via appcfg has been - in my experience - limited to which of the two commands I execute. That said, I've no experience with Sphinx.
Sphinx compiles documentation, running it on a webserver makes as much sense as running gcc on a webserver.