inrichten Cloud Server

install ubuntu 18.04

configureer de firewall UFW

Uncomplicated Firwall  (interface to iptables)

https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu-18-04

    sudo ufw default deny incoming
    sudo ufw default allow outgoing
    sudo ufw allow ssh
    sudo ufw allow 80
    sudo ufw allow 8080
    sudo ufw enable


zorg dat apache niet automatisch opstart:
sudo update-rc.d apache2 disable
sudo systemctl disable apache2

Install Nginx

zie https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-18-04

check webserver

What you're seeing is the index.html file that was installed by Apache. Do not trust solely the Index page being served as an indicator of the Web Server being used!

Just because you're seeing the Apache "default" page, doesn't mean that you're actually seeing Apache running, you're just seeing the 'default page' that was installed. Neither NGINX nor Apache will overwrite the index.html file in the default web root if it was already present (in an ideal situation), so whichever was present first is actually the one that installed the index.html file - it won't change just because you installed a different webserver.

You can confirm this by doing: sudo rm /var/www/html/index.html && echo "I am testing things!" | sudo tee /var/www/html/index.html and then refreshing your browser - you'll see that it's different content at this point.

If the nginx software at install time sees an index.html file already in the default webroot /var/www/html/, it is supposed to not overwrite it. This is normal, so users who use the default docroot for their websites don't lose their data.

What we need to do is confirm what Web Server is actually in use.
Always use actual command line tools to verify the web server software in use.

Leveraging sudo netstat -tulpn | grep :80 we can get an idea of what web server is in use:

$ sudo netstat -tulpn | grep :80
tcp6       0      0 :::80                   :::*                    LISTEN      1258/apache2

As you can see, this is an Apache2 web server listening on port 80.

Conversely, if the server is nginx you see something like this:

$ sudo netstat -tulpn | grep :80
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      2772/nginx: master 
tcp6       0      0 :::80                   :::*                    LISTEN      2772/nginx: master

You can also determine if it's Apache2 or NGINX running by checking the output of one of the following commands:

$ pidof apache2
$ pidof nginx

Depending on which of these provides output, you can determine which web server is actually in use.

Install Flask

 https://www.digitalocean.com/community/tutorials/how-to-serve-flask-applications-with-uswgi-and-nginx-on-ubuntu-18-04


let op foutje moet zijn : 
 python3 -m venv myprojectenv

Let op bij stap 5 creating a systemd unit file


in  /etc/systemd/system/myproject.service is belangrijk dat je group=www-data gebruikt ander krijg je later bad gateway 502 errors

[Unit]
Description=uWSGI instance to serve myproject
After=network.target

[Service]
User=ilcapo
Group=www-data
WorkingDirectory=/home/ilcapo/myproject
Environment="PATH=/home/ilcapo/myproject/myprojectenv/bin"
ExecStart=/home/ilcapo/myproject/myprojectenv/bin/uwsgi --ini myproject.ini

[Install]
WantedBy=multi-user.target

symbolic links

ga in directory :  unlink default

maak een link:   sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/default

uwsgi installatie

let op zie speciale Post hierover

The uWSGI install will fail unless you have a complete Python installation. In particular, you need to have the python3-dev package and the libssl-dev package installed. (See this post.)

(sam) joe@helium:~/venvs$ which -a python3
/home/joe/venvs/sam/bin/python3
/usr/local/bin/python3
/usr/bin/python3

full stack python WSGI

uit  https://www.ultravioletsoftware.com/single-post/2017/03/23/An-introduction-into-the-WSGI-ecosystem

start Anaconda promt

conda env list
activate myFlask
start spyder       <---spyder wordt als seperateproces opgestart







Enter WSGI

WSGI (pronounced wiz-gee) stands for Web Server Gateway Interface and it's a spec for a software interface between a web server and a python application. 

The point of WSGI is to allow any web server to work with any Python application as long as both sides implement the spec. 

 You can see the spec here in PEP 333, but basically it boils down to the concept of the python app making a callable object (e.g. a function) available to the web server. When the web server receives a request from the client that should be processed by the python app, it calls this function. The python app runs and returns the result to the web server, and the server passes it on to the client.

Here is an example of a basic python app that implements the WSGI spec:

Here, the function application is the callable object I referred to above. This is the function that the web server will call when it wants the python app to process a request. It takes two parameters:

def application(environ, start_response):
    start_response('200 OK', [('Content-Type', 'text/plain')])
    return [b'Hello World!']

• environ - a dictionary that contains information about the request and various settings from the WSGI server that made the call.
• start_response - a function that must be called by the python application to start the HTTP response. If the python app does not call this method, the request will not be properly processed by the server.

Also notice that the return value of the application function is the actual response body. Returning a value is optional. Of course, not all HTTP responses have bodies (e.g. HTTP status code 204).

And that's basically it. As long as the Python app provides this callable and the web server is capable of invoking it and passing in the correct arguments, any combination of web server and Python app can work together.

If you'd like to actually see a WSGI app run, it's easy to do. First you'll need a WSGI compliant server. I recommend uWSGI, which has a simple command line interface. It can be installed by running

pip install uwsgi

Save the python script I listed earlier into a file called app.py. Run the uWSGI server by typing this on the command line:

uwsgi --http :8080 --wsgi-file app.py

and browsing to http://localhost:8080

Notice that the python app has no import statements. There are no external libraries or frameworks used. It's as plain a python app as they come. The magic is all in the implementation of the WSGI spec. It's important to note that if you don't name the function "application" it won't work. That's the default name that the uWSGI server expects, but it can be configured to work with a different name if you like.

How it all fits together

The confusing part about WSGI is that there is a lot of history here, a lot of options, and the documentation, while not bad, isn't always that clear. Since both Flask and uWSGI are popular options in this realm, I'm going to focus on them and clear up some confusing aspects of how they work.


Werkzeug

You may have heard of this framework in passing or seen references to it in your Flask application. Werkzeug (pronounced work-zoig or vairk-zoig if you want to get technical), is a library written by Armin Ronacher that consists of a large set of utilities designed to make writing WSGI compliant Python applications easier.


Flask

Flask is a popular framework for writing WSGI complient web applications in Python. It was also written by Armin Ronacher and is implemented using the Werkzeug library. You might have noticed that Flask comes with its own development level server. Well, this is actually Werkzeug's dev server being exposed through Flask.


uWSGI

uWSGI is a popular web server that implements the WSGI standard. Don't get confused by the name. WSGI is a specification, uWSGI is a web server. That little "u" in the front makes a big difference. It's pretty common to pair Flask and uWSGI since they both talk WSGI. The uWSGI server is a full featured HTTP server that is quite capable of running production web apps. However, it's not as performant as nginx at serving static content, so it's pretty common to see nginx sitting in front a uWSGI server.


uwsgi

Here's where some poor naming choices make things even more confusing. So we know WSGI is a software spec, uWSGI is a server, so what the hell is uwsgi? When it's spelled using all lowercase letters, it refers to a binary protocol for connecting the uWSGI server to other applications. As you no doubt recall from the above paragraph, it's common for uWSGI to be used in conjunction with nginx. Well, the uwsgi protocol is how the two web servers talk to each other.

Here is the basic flow of data from the client through the python app:

End communication

So there you go, a brief and hopefully useful introduction into the world of WSGI.

Anaconda config

soms krijg je na installatie van Anaconda een CondaHttpError als je wil updaten via conda.
Disable SSL verificatie via:

 conda config --set ssl_verify no

start Anaconda promt

conda env list

conda create --name flask 
activate myFlask


conda create  -p O:\Input\03_ZichtenGrip\python\environments\ENV_flask_dash

clean conda

conda clean --all --dry-run

Installeer Jupyter lab en notebook

conda install -c anaconda jupyter
conda install -c conda-forge jupyterlab

how to conda environment to jupyter lab

$ conda activate cenv
(cenv)$ conda install ipykernel
(cenv)$ ipython kernel install --user --name=<any_name_for_kernel>
(cenv($ conda deactivate

start spyder       <---spyder wordt als seperateproces opgestart

start jupyter lab --browser firefox 

start notebook in firefox

start jupyter notebook --browser firefox

maak identieke omgeving  

server 1:  conda list --explicit > spec-file.txt 

server 2: conda create --name myenv --file spec-file.txt 

Environment.yml

 conda env export > environment.yaml



 https://medium.com/@chadlagore/conda-environments-with-docker-82cdc9d25754

Dockerfile 

 FROM continuumio/miniconda3
RUN conda create -n env python=3.7
RUN echo "source activate env" > ~/.bashrc
ENV PATH /opt/conda/envs/env/bin:$PATH

Regressie

Voorbeeld van Regressie

Lineaire Regressie

- Prediction of a numerical value
- Function Fitting

Lineair Regression Model 

 Evaluation