I have a Python application deployed in the app platform, but I need a javascript runtime, for example a node, can I somehow install it additionally?
App Platform uses containers.
For the natively-supported platforms|languages, DO has created|used buildpacks to build the container image for your app but, if these buildpacks are insufficient for your needs, you can write and use a Dockerfile directly.
You will then use the spec.yaml to define HTTP ports, healthchecks, routes etc.
When App Platform launched, I blogged an example using Rust as this is not natively-supported.
Related
Recently I have started a Django server on Azure Web App Service, now I want to add a usage of "ChromoDriver" for web scraping, I have noticed that for that I need to install some additional Linux packages (not python) on the machine. the problem is that it gets erased on every deployment, does it mean that I should switch to Docker ?
Container works, but you can also try to pull down the additional packages in the custom start up file without messing around the machine after the deployment
https://learn.microsoft.com/en-us/azure/developer/python/tutorial-deploy-app-service-on-linux-04
I'm considering building app with Django for only one user that would run application locally on windows. I read about containerizing Django apps, but it's new for me.
My goal is to run Django server on one click like a standard windows app and connect to it on localhost and interact with web browser. It is even possible?
It is possible, but this may not be the best solution. If you want to release a Django app that can be installed on your client computer, you usually need to ensure all the dependencies are shipped with the app.
Containerising your application means it will depends on Docker runtime (or any container system you use). You will have to setup Docker with your app, or ensure your client has Docker on his machine to run it. If the destination machine runs Windows or macOS, you will need to setup docker-desktop which may be more complicated than standard Docker runtime (linux only).
But if you decide to ship your app without containerising it, it will only depends on a Python interpreter and some dependencies (Django, dateutil, etc.). In such case, using python tools like virtualenv, you may prepare a ready-to-run application by creating the venv and installing dependencies at "build time". Then, with a proper setup (MSI for Windows or DMG for macOS), you may be able to distribute the final application so the client can install and run it without any additional step (you do all the hard job yourself).
Django app can be convert into .exe but it wont work as local server while click .exe because runserver command and some of django service wont support on this way as per my experiment.
I have a Django project. I am considering adding Docker to it before deploying to Elastic Beanstalk. I am very new to Django and Docker and want to know what are the benefits of using Docker when deploying a Django app to Elastic Beanstalk. Thanks!
The general benefits of using Docker in EB, as compared to regular Python EB environment portability and reproducibility.
If you bundle your django app as Docker container, you know that you your development environment will be exactly same as your production one. All the dependencies, package versions, tools will be same in the container, regardless if it runs on your local workstation, home laptop or on EB platform.
However, when you use regular Python platform, the portability and reproducibility can be difficult to guarantee. The current Python platform is based on Amazon Linux 2. So the question is, is your development environment at home or work exactly same? Usually this is not the case, which often leads to issues in the vain of "It works on my local ubuntu workstation, but not on EB".
Also, one day you may decide to migrate your app out of EB or even AWS. It will be much easier to do that when using docker. This is because EB is a custom product from AWS, not available in other could providers with its own settings and requirements.
EB supports two types of docker-based environments:
single-docker
multi-docker
Depending on your requirements, you would have to use one of them. Each of them has its own use-cases, which I think are out of the scope to discuss for this question.
From what I am aware, Google Cloud Functions only allows you to deploy NodeJs or Python scripts.
Question: How would I be able to deploy a simple Hello_World.cpp on Google Cloud Functions? For example, writing a hello world HTTP function.
What are alternate methods to do this? I want to use serverless approach, since it's cheapest method. Therefore, that is why I'm going with Google Cloud Functions. Would I have to use docker in order to run C++ files? I've been stuck on this for a while and any guidance or help would be appreciated.
You can compile your C++ function into a WebAssembly module using emscripten. Then you can call it from a small nodejs glue code.
I built an example for you here:
https://github.com/ArthurSonzogni/gcloud-cpp-starter
You can run C++ Code by node.js on google cloud functions (tested with node.js 10)
how to using C++ and N-API (node-addon-api) https://medium.com/#atulanand94/beginners-guide-to-writing-nodejs-addons-using-c-and-n-api-node-addon-api-9b3b718a9a7f
use https://console.cloud.google.com/functions and click CREATE FUNCTION to upload .zip or gcloud functions deploy --runtime nodejs10 --trigger-http
The trick is when you zip file you need to remove /build and /node_modules folder then use command line by cd to folder of index.js and 'zip your_name.zip -r *'
ps. when I use firebase deploy --only functions it will error because it doesn't know file addon.node format (in fact it shouldn't read this file because it need to be recompiled) but I think if we using gcloud functions command line with .gcloudignore for /build and /node_modules it will success https://cloud.google.com/functions/docs/deploying/filesystem
HOW DOES IT WORK
I think when you deploy node.js source code to cloud functions it will run npm install and your C++ code will be compiled too (like npm run build will be auto run after npm install)
You can't use C++ on Cloud Functions, period. You can only use Node.js 6.14, Node.js 8.11.1 (beta) and Python 3.7 (also beta).
If you wish to use C++ in GCP with a serverless approach, my best suggestion would be running your own Custom Runtime in App Engine. You would still need to configure some instances options, but you don't have to manage servers and so on.
You can only use App Engine Flexible Environment (or, of course, standard VM architecture, Compute Engine). Extract from the docs (https://cloud.google.com/appengine/docs/flexible/):
Runtimes - The flexible environment includes native support for Java 8
(with no web-serving framework), Eclipse Jetty 9, Python 2.7 and Python 3.6,
Node.js, Ruby, PHP, .NET core, and Go. Developers can customize these
runtimes or provide their own runtime by supplying a custom Docker image
or Dockerfile from the open source community.
As an interesting side note, Google Serverless Containers will give you the chance to deploy your dockerized application but in a serverless flavour (in fact it's built on top of Google Cloud Functions technology). It's currently in Alpha stage.
The question is in the title.
I need to deploy a Django application in a local network (i still don't know how to do but i suppose it's quite easy) but i still need to develop it. My question is how to do to allow users to use the application while i'm still developing it ?
Is it a solution to keep to versions of the application, one deployed and one in development ? In this way, I can replace the application deployed by the newly developed one when I finish coding it.
Another question concerns the database, can I still modify the database if I just add new models without touching existing ones ?
Thank you in advance,
This is a good blog entry that covers deploying Django using Heroku. I'll give you a quick rundown of what makes all the different technologies important:
Git
Git, or any other version control system, is certainly not required. Why it lends itself to deploying Django projects is that your usually distributing your application by source, i.e. your not compiling it or packaging it as an egg. Usually you'll organize your Git repository as such that updating your application on the server only requires you to do a checkout of the latest sources--nothing else.
virtualenv and pip
This, again, is not a strict requirement, but I'd strongly suggest you take the time to familiarize yourself with virtualenv and pip if you already haven't done so, since it's going to make deploying your Python applications across different runtime environments, local or remote, a breeze.
Basically, your project will need to have at least Django and Gunicorn available on the Python path, possibly even a database driver. What that means is that every time you try to deploy your application somewhere you'll have to install Python and do the easy_install dance all over.
virtualenv will redistribute a Python installation, which in turn means that the new Python instance will, by default, have it's very own Python path configuration relative to the installation. pip is like easy_install on steroids, since it supports checking out Python dependencies directly from code repositories and supports a requirements file format with which you can install and configure all of your dependencies in one fell swoop.
With virtualenv and pip, all you'd need to do is have a simple text file with all your dependencies that can be parsed with pip and an installed Python distribution on the machine. From there you just do git checkout repo /app/path; easy_install virtualenv; virtualenv /app/path; ./app/path/scripts/activate; pip install -r /app/path/requirements.txt. Voila, Gunicorn, Django and all other dependencies are then installed and available immediately. When you run the Gunicorn Django script with the Python instance in /app/path/scripts, then the script will immediately have access to the Gunicorn sources and it will be able to locate your Django project which will have access to Django and other dependencies as well.
Gunicorn
This is the actual Python application that will manage your Django instance and provide an HTTP interface that exposes it to HTTP clients. It'll start several worker processes which will all be distinct Python virtual machines loaded with the sources of your application and it's dependencies. The main Gunicorn process will in turn take charge of managing which worker processes manage which requests for maximum throughput.
The basic principle of wiring Nginx and Gunicorn
The most important thing to observe is that Nginx and Gunicorn are separate processes that you manage independently.
The Nginx Web server will be publicly exposed, i.e. it will be directly accessible over the internet. For requests to static media, such as actual images, CSS stylesheets, JavaScript sources and PDF files accessible via the filesystem, Nginx will take charge of returning them in the response body to HTTP clients if you configure it to look for files on the path where you configured your project to collect static media.
Any other request should be proxied to your Gunicorn instance. It will be configured to listen to HTTP requests on a certain port on the loopback interface, so you'll using Nginx as a revers proxy to http://127.0.0.1:8080 for requests to your Django instance.
This is the basic rundown for deploying your Django projects into production that should satisfy the needs of 95% Django projects running out there. While I did reference Nginx and Gunicorn, it's the usual approach when it comes to setting up any Web server to act as a reverse-proxy to a Python WSGI server.