As per official documentation there can be only one app engine instance per project,
My question is, is it possible to deploy multiple independents django application to appengine ?
In other terms using appengine as a hosting platform for django apps .
Nowhere in the documentation or tutorials i have seen something like that done
How about using it to deploy multiple independents wordpress instances ?
Thanks in advance
What you're looking for is called App Engine Services.
As well you have mentioned, you only can have 1 App Engine App per project, but this app can have multiple services which for your case can be translated as multiple apps.
Every single service will have its own app.yaml. Let's say you have the following struct:
Apps/
├── app1
│ ├── app.yaml
│ └── django_files
├── app2
│ ├── app2.yaml
│ └── django_files
├── app3
│ ├── app3.yaml
│ └── django_files
└── app4
├── app4.yaml
└── django_files
Then the app.yaml can contain the following:
runtime: python38
#no adding the service: because this will be the default service or app
#more configs go here...
For the app2.yaml
runtime: python38
service: app2
#more configs go here...
You will notice that we added the service config which defines to which service this app will be deployed. If the service is not defined, the app will be deployed always to the default service.
The services are isolated, i.e., they do not communicate but if needed those can interact between them.
And finally, you can map every service to a custom domain. For example, mydomain.com can route to the default app, app2.mydomain.com be routed to the second one an so on. You can learn how to map a custom domain here and how to route the requests to your services here.
The previous answer is the right one to achieve what you want to do. However, I'm writing this answer to say you to not do this!
To create a project is free, you can create 1 project per app.
With App Engine, you have 28h of F1 instance free per day and per project. Each new project allows you leveraging this free tier!
The wordpress instance are differents, so the database are different. If you use the same project the same database is used. You can also create different database (or schema inside the same database instance) for each app, but at the end, all the wordpress instance will be able to reach the database instance of others app.
If you have custom need, cleaning or something special to perform, doing this on only one wordpress instance deploy on only one project is easier and with less risk on the side wordpress instance.
There were my pieces of advice!
Related
I have finished the tutorial for sphinx-versioning completely. After running the following command, I obtained a new index.html.
sphinx-versioning build -r feature_branch docs docs/_build/html
open docs/_build/html/index.html
However, I want to have version number such as 0.5.0 and 0.6.0 instead of the branches. How to stack the documentation with version numbers instead of the branches? I can't seem to find it in the official sphinx-versioning documentation.
In Pyramid, we create branches with the version number, e.g., 1.10-branch. Alternatively you can use git to tag a version number, then go into the RTD Admin for your project, and under "Versions" activate it for publication.
In the end I realized that sphinx-versioning does not recognize tag, instead it will only recognize release.
However, another problem with sphinx-versioning is that if you are using the autodoc extension, the documentation generated will be the same as your existing version across all branches and versions. The reason is that the autodoc will only generate the documentation with the package you are having on your computer now, it will not automatically download the old package and generate the older version of documentation for you. But there is a workaround for it.
Complete solution (hacks)
Say you have two releases v1.0 and v2.0 on GitHub.
Then you do a git checkout v1.0, and build the html with sphinx-versioning build <your source location> output1.
Similarly, do git checkout v2.0, and build the html with sphinx-versioning build <your source location> output2.
Then you will have two output folders like this:
output1
├── index.html
├── master
├── v1.0
└── v2.0
output2
├── index.html
├── master
├── v1.0
└── v2.0
I am omitting other unimportant files here.
Now, we just need to delete that v1.0 folder under output2 and move the v1.0 folder from output1 to output2. Then you will have a perfectly working autodoc generated documentation together with a working versioning.
Of course, the drawback for this is that the build time would increase exponentially as you have more versions and you need to manually build so many versions. But still works as a quick fix. Maybe we can write a script to do this for us so that we do not need to build them manually?
TL;DR
sphinx-versioning does not support versioning that well especially when you use autodoc. There are hacks to make it works, but it would be very slow and tedious.
If you want something convenient and don't mind having ads on your documentation, just follow Steve Piercy's suggestions and use the hosting service provided by RTD.
I’ve been trying to use Sagemaker to run my custom MXNet training job. In all the examples I’ve seen, the code sample looks like this
estimator = MXNet(‘train.py’, role=role, other_params)
estimator.fit(inputs)
What if my train.py relies on a custom module? Given a directory structure like so
.
├── awesome
│ ├── __init__.py
│ └── lib.py
└── train.py
With my train.py file importing from awesome/lib.py, what’s the best way for me to deploy this job on Sagemaker without going through the hassle of creating a Docker container.
Note: all the code in the custom module is just regular mxnet code, organized across various files and helper methods
You can use the parameters source_dir to point to the code location, and a requirements.txt file to add dependencies. This will avoid to touch docker at all. You can see those parameters in the SDK documentation ("Use third party library"), they are available both for training and deployment. See here an mxnet deployment example with additional dependencies in a requirements.txt
https://github.com/aws-samples/sagemaker-yolov3-detection-server/blob/master/mxnet_detection_serving.ipynb
We currently host a large number of containerized websites in Kubernetes and we are exploring using Google App Engine to host these sites but we cannot figure out how to host a large number (hundreds) of websites in a single Google App Engine account.
At first glance it seemed that every website will be a separate project but then it became clear that there is a soft limit of twenty projects (and we might end up hosting hundreds of sites) so this did not seem to be the correct approach. We then explored using a single project with dispatch.yaml to route between the sites. Dispatch.yaml only allows for ten entries which mean that it will not work. Is there any other approach we are missing? Our dispatch.yaml routing looked like this:
- url: "example2.com/*"
service: my-second-website
None of the options we explored provided a scalable or viable solution. Any help or advice will be highly appreciated.
What you need is one App Engine instance with multiple services (one for each website) and multiple versions in each service (if needed).
e.g:
App Engine instance
├── website01-service
│ ├── website01-version01
│ ├── website01-version02
│ └── website01-version03
│
└── website02-service
├── website02-version01
├── website02-version02
└── website02-version03
This is an example setup from Quickstart for Python 3 in the App Engine Standard Environment documentation.
Download the files from git repository as stated in Download the Hello World app section.
Copy the hello_world sample files in two different directories. e.g. website01 and website02.
You should have something like this:
├── website01
│ ├── app.yaml
│ ├── main.py
│ ├── main_test.py
│ └── requirements.txt
└── website02
├── app.yaml
├── main.py
├── main_test.py
└── requirements.txt
In website01/app.yaml add service: website01 and in website02/app.yaml add service: website02. This will deploy each app in different App Engine service.
In website01/main.py change return 'First website!' and in website02/main.py change return 'Second website!' (This is just to confirm after deployment that 2 different websites are running).
In the /website01 directory execute $ gcloud app deploy --version website01-version01 and in /website02 directory execute $ gcloud app deploy --version website02-version01
After a successful deployment, you should see 2 different versions running in Google Cloud Console > App Engine > Services page.
When clicking on both links new tabs will open and you will see your two different websites running in the same App Engine instance with two different links. The links should appear as following:
website01 -> https://website01-dot-[PROJECT_ID].appspot.com/
website02 -> https://website02-dot-[PROJECT_ID].appspot.com/
Have you tried requesting that your project limit be increased? I think that's the only good way to make this work.
If you attempt to exceed your project limit, the console will prompt you to fill out a request form. This happens when you try to create a project but you have already reached your quota. The form will require you to specify the number of additional projects you need, along with their corresponding email accounts, billing accounts, and intended uses.
https://support.google.com/cloud/answer/6330231?hl=en
You could do this with a single project & single service/app.yaml, if your ok with the url for each website being something like :
www.website1.com/website1/
www.website2.com/website2/
www.website3.com/website3/
etc
Then you could use the handlers in app.yaml to do the routing (along with some light server code to redirect if someone tries to visit www.website1.com/website2/). The biggest issue with doing it this way is every time you'd deploy you would be deploying all 100 of your sites.
I'm working collaboratively on Google App Engine project. Other contributors have committed a basic App Engine project structure:
└───src
├───main
├───java
│ └───com
│ └───[...]
└───webapp
├───css
├───fonts
├───img
├───js
├───partials
└───WEB-INF`
The java directory contains the server-side app written in Java.
The webapp directory contains predominantly client-side code including a basic AngularJS app. However it's also home to WEB-INF which configures the webapp and is not client-side app code.
If I wanted to start using Yeoman to manage the client-side app and get all the benefits that Grunt and Bower bring, how would I do this? I've only ever scaffolded out Yeoman apps from the beginning and never from a predefined Google App Engine project.
I can think of two options:
Remove everything under webapp (excluding WEB-INF) and run
Yeoman from within the webapp folder. This feels a little
ungraceful.
Separate out the App Engine project from the client-side
Angular app and scaffold out an Angular app using Yeoman.
To be clear, I'm looking for information on the means of introducing Angular using Yeoman, rather than just end product of Angular existing in an App Engine app.
I found this specific example of an App Engine and AngularJS example.
Perhaps this might be a decent starting point for you to work with.
How would would you deploy the output of the angular-fullstack Yeoman generator to Azure? The generator produces output like this, i.e. two folders - client and server.
├── client
│ ├── app - All of our app specific components go in here
│ ├── assets - Custom assets: fonts, images, etc…
│ ├── components - Our reusable components, non-specific to to our app
│
├── e2e - Our protractor end to end tests
│
└── server
├── api - Our apps server api
├── auth - For handling authentication with different auth strategies
├── components - Our reusable or app-wide components
├── config - Where we do the bulk of our apps configuration
│ └── local.env.js - Keep our environment variables out of source control
│ └── environment - Configuration specific to the node environment
└── views - Server rendered views
I'd like to deploy this to Microsoft Azure, and ideally using Git deploy. How would I go about that?
Update
Here's what the deployment file structure looks like in Azure.
Here is the short version:
Create a new blank Web App in Azure.
In the Deployment options, select 'Set up continuous deployment'.
Select 'Local Git Repository'.
This will give you a Git Remote for the blank azure Web App to allow you to push to it. Which means you can do this:
git remote add azure [URL for remote repository]
git push azure master
Here is the longer version (it is for a node app - but the same concepts apply).