Categories

Meta

Tag: Web

You just built an application that connects with a Database on your local machine, but now you want to share it with the world. But you don’t want to share everything about your application with the world.

Azure web apps supports a number of different web platforms, but to effectively build while maintaining code on GitHub we need to keep configuration details of our app private including the connection string for our database.

In this case we’re going to be using a Node JS application connected to a Mongo Database hosted on a Virtual Machine.

Before we get started…
Do you have a MongoDB up and running?
Nope. – Read this post!
Yep! – Great keep going!

For reference, I’m starting with a chat application originally written by fellow evangelist Rami Sayar for an excellent Node Course he taught recently.

The Steps:
1. Clone or fork the repository
2. Create an App Service
3. Connect App Service to Repository
4. Add app settings in Azure Portal
5. Try it out!

1. Clone or fork the repository

The project I’m using for this demonstration is found here: Github
Now clone the project to your local machine, or fork it in GitHub.

Take a quick look at these files:
– package.json : checkout out the dependencies of the project, notice how we’re using the official mongodb driver
– mongoClientTest.js and dbTest.js : provide other examples/test files to run, just substitute your ip address of where mongo is being hosted to make sure you’re able to connect.
– app.js : this is the main file that will be run by Azure Web Apps (app.js or server.js will automatically be started by the cloud when deployed). Also, in app.js you’ll see we set ‘db’ using process.env app.set('db', process.env.DB ); – we’ll be using that in step 4.

Once comfortable with the files locally or in GitHub we’re ready to spin up our App Service in Azure.

2. Create an App Service

App Service is a PaaS service offered by Azure to make deployment of website/web services simple and easy to maintain, develop against, and scale.

To begin select the ‘Plus’ button in the upper left corner and select web+mobile, then select Web App:

Now configure your web app:

You may have to create a app service plan and resource group if you haven’t created one yet, for more info on this portion of the architecture click here and here

You’ll see this icon on your dashboard while the resource is spinning up:

Once running the portal should automatically take you to that resource, if not you’ll see it on your dashboard:

Here’s the overview pane and the items we’ll be using in the rest of this tutorial highlighted:

3. Connect App Service to Repository

Now that we have an app service, let’s connect it to our repository.
There are a number of options for deployment.

In this case we’re going to deploy from GitHub, but we could have also used a local repository by adding Azure as a remote repo.

Azure will detect changes made to the repository on GitHub and redeploy the project. This makes deployments during hackathons super easy.

Note: You can also select Local Git Repository if you’ve liked to keep your code off of GitHub and add Azure as a remote repository git add remote azure "http://git.asdfgafdgasdfgasdf" – will be displayed in overview portal once initialized.

You’ll then be asked to login to GitHub so it can access the list of your repos.
Select your forked repo or the cloned repo you’ve committed to GitHub:

Once selected you’ll see a notification in the top right corner with a loading bar for the deployment:

Once that’s finished, you have code ready to roll in the cloud.
Azure has automatically installed the packages listed in your package.json and found the file named server.js to deploy. Next let’s configure it to talk to Mongo!

4. Add App Settings in Azure Portal

Now we have a project connected and deployed on Azure, but it won’t store the data anywhere, because a connection string hasn’t been included in the environment variables (aka application settings).

To add our monogodb to the project we just need to include the variable name and the connection string.
In our project, as noted before, we set db using process.env.DB

Select application settings and scroll down to until you see app settings then enter into the two empty fields “DB” and the connection string mentioned earlier: mongodb://40.83.182.555:27017/test
Like this:

Then hit save!

Go back to your website and try entering some chatter!

Try it out!

If you visited the page it should look something like this:

In the middle of the above screen shot you can see a terminal with a connection to the VM and same data in the MongoDB.

If you’re running into issues try connecting using dbTest.js or mongoClientTest.js after you add the specific IP for your VM hosting mongo.

Hope this made it super simple to connect your application to a database using Azure Web Apps.
Please let me know if you run into any issues in the comments below.

Before we start make sure you can ssh into your machine and run
$sudo apt-get update

It’s a four step process:
1. Open the appropriate port on Azure
2. Install pip, virtualenv, virtualenvwrapper, and flask
3. Write our code and run it
4. Keep it running with Gunicorn

1. Open the appropriate ports on Azure
Go to you virtual machines landing:

Then select the resource group in the top left corner:

Resource groups are the way Azure breaks down how our VM interacts with the internet, other vms, storage, and public/private networks.

Top open the port we need to change our network security group, which is represented by the shield. (Underlined in the screenshot above)

Then select settings -> Inbound Security Rules:

This will allos us to open up our VM to the public internet so we can visit what’s presented at the port like a regular website.

You should see SSH already included, that’s the port we’re using in our ssh client/terminal.

We’re now going to add two new Inbound Security Rules one called FlaskPort where we’ll set the destination port range to 5000 and use for debugging. The second will be called FlaskProduction that we’ll use to deploy our complete app.
Here’s the configuration panel for FlaskPort:
Press okay to accept the settings.

And the other panel for FlaskProduction:
Again press okay to accept the settings.

Notice how the ‘Source Port Range’ is ‘*’ that just means that we’ll accept connections from the port of any machine. This tripped me up the first time.

In a couple seconds the port will be open we’ll be ready to visit it, but nothing will be there because we haven’t create an application server.

To do that we’ll install the basics.

2. Install pip, virtualenv, virtualenvwrapper, and flask

To use Python effectively we utilize virtual environments to help keep our various python project and required libraries in order.

If you get lost in these steps or want more context Gerhard Burger provides the same setup on a very helpful post on askubuntu.

First we install pip:$ sudo apt-get install python-pip

Second we install virtualenv and virtualenvwrapper

$ sudo pip install virtualenv
$ sudo pip install virtualenvwrapper

Third we configure virtualenv and virtualenvwrapper

Create a WORKON_HOME string which will contain the directory for our virtual environments. We’ll name it vitualenvs

$ export WORKON_HOME=~/.virtualenvs

Now we’ll create this directory.

$ mkdir $WORKON_HOME

And add this to our bashrc file so this variable is defined automatically every time we hit the terminal.

$ echo "export WORKON_HOME=$WORKON_HOME" >> ~/.bashrc

Then we’ll setup virtualenvwrapper by importing its functions with bashrc.

$ echo "source /usr/local/bin/virtualenvwrapper.sh" >> ~/.bashrc

You can see the additions to our bashrc file by opening it with nano. Scrolling down to the bottom you should see two lines like this:

Then implement your changes.

$ source ~/.bashrc

Here’s what all that looks like all together:

Fourth, let’s create our first virtualenvironment

$ mkvirtualenv venv

And take a look at the currently installed packages$ pip list

Like so:

Now we can install all of the python packages we want without risk of needing to reinstall python!

Fifth, install flask:

$ pip install flask
$ pip list

3. Write our code and run it!
Our first app is a simple site that shares an image.

We’re going to create a folder called Photo-App that contains two folders and an app.py that will serve our clients.

To change to our home directory:$ cd ~
And create our new folder:$ mkdir Photo-App

You’re using gunicorn to start app hosted at 0.0.0.0:8000 with the reload tag configured.
The reload will look for changes in your code and reload the server everytime you change any server side stuff. It won’t auto-reload for HTML changes, but will reload them once you make a change to the python code.

This week I’ve been making progress on the Huggable Cloud Pillow website.

In the process I’ve learned about some sweet stuff you can do with Javascript, Python, and Flask-SocketIO.

The first thing to take note of is Flask.

Flask is the tiny server that allows us to host websites using Python to deliver content to the client. While on the server side you can manage complicated back ends or other processes using Python in conjunction with Flask.

This type of development is nice, because you can start seeing results right away but can take on big projects easily.

It might not be the most robust Framework, but its great for small projects…

If you want to get into Flask Web Development checkout this extensive MVA.

Small and simple, Flask is static on its own. This allows us to present static content, like templates and images easily and deals with input from the user using RESTful calls to receive input. This is great for static things with lots of user actions, but if we want something a bit more dynamic we’re going to need another tool.

In this case I’ve found Flask-SocketIO, similar to Flask-Sockets but with a few key differences highlighted by the creator (Miguel Grinberg) here.

Sockets are great for is providing live information with low latency. Basically, you can get info on the webpage without reloading or waiting for long-polling.

There are lots of ways you can extend this functionality to sharing rooms and providing communication with users and all sorts of fun stuff that is highlighted on GitHub with a great chunk of sample code. The following demo is based off of these samples.

For my project, I need the webpage to regularly check for differences in the state of the cloud and present them to the client, while also changing the image the user sees.

At first I tried to implement it using sockets passing information back and forth, but that wasn’t very stable.

The solution I’ve found, uses a background thread that is constantly running while the Flask-SocketIO Application is running, it provides a loop that I use to constantly check state of our queue.

Let’s break it down…
a. I need my website to display the current state of the cloud.
b. The Flask application can get the state by query our azure queue.
c. Once we determine a change of state we can display that information to the webpage.
d. To display the new state to the webpage we need to use a socket.
e. And pass the msg to be displayed.

This demo intends to break down problem a, c, d, and e.

I’ve created this little guide to help another developer get going quickly, with a nice piece of code available on GitHub.

The five steps to this little demo project are as follows:
1. Install Flask-SocketIO into our Virtual Environment
2. Create our background thread
3. Have it emit the current state to our client
4. Call the background thread when our page render_template’s
5. Have the Javascript Catch the emit and format our HTML.
Celebrate! Its Friday!

1.

Flask-SocketIO is a python package that is available for download using

This emit will be sending to the client (Javascript) a message called ‘message’.

When the Javascript catches this message it will be able to pull from the python dicionary msg.data and msg.time to get the result of this package.

4

So how do we call background_stuff?

We can call it wherever we want, but for this simple example we’ll put it right in our ‘/’ base route. So when we navigate to 127.0.0.1:5000 (Local Host) we’ll see the result of our background thread call.