The first objective of this lab is to get familiar with software tools that will allow us to build a complete web infrastructure. By that, we mean that we will build an environment that will allow us to serve static and dynamic content to web browsers. To do that, we will see that the apache httpd server can act both as a HTTP server and as a reverse proxy. We will also see that express.js is a JavaScript framework that makes it very easy to write dynamic web apps.

The second objective is to implement a simple, yet complete, dynamic web application. We will create HTML, CSS and JavaScript assets that will be served to the browsers and presented to the users. The JavaScript code executed in the browser will issue asynchronous HTTP requests to our web infrastructure (AJAX requests) and fetch content generated dynamically.

The third objective is to practice our usage of Docker. All the components of the web infrastructure will be packaged in custom Docker images (we will create at least 3 different images).

• This is a BIG lab and you will need a lot of time to complete it.
• We have prepared webcasts for a big portion of the lab (what can get you the "base" grade of 4.5).
• Be aware that the webcasts have been recorded in 2016. There is no change in the list of tasks to be done, but of course there are some differences in the details. For instance, the Docker images that we use to implement the solution have changed a bit and you will need to do some adjustments to the scripts. This is part of the work and we ask you to document what the required adaptations in your report.
• The webcasts present one solution. Feeling adventurous and want to propose another one (for instance, by using nginx instead apache httpd, or django instead of express.js)? Go ahead, we LOVE that. Make sure to document your choices in the report. If you are not sure if your choice is compatible with the list of acceptance criteria? Not sure about what needs to be done to get the extra points? Reach out to the teaching team. Learning to discuss requirements with a "customer" (even if this one pays you with a grade and not with money) is part of the process!
• To get additional points, you will need to do research in the documentation by yourself (we are here to help, but we will not give you step-by-step instructions!). To get the extra points, you will also need to be creative (do not expect complete guidelines).
• The lab can be done in groups of 2 students. You will learn very important skills and tools, which you will need to next year's courses. You cannot afford to skip this content if you want to survive next year. Essentially, this means that it's a pretty bad idea to only have one person in the group doing the job...
• Read carefully all the acceptance criteria.
• We will request demos as needed. When you do your demo, be prepared to that you can go through the procedure quickly (there are a lot of solutions to evaluate!)
• You have to write a report. Please do that directly in the repo, in one or more markdown files. Start in the README.md file at the root of your directory.
• The report must contain the procedure that you have followed to prove that your configuration is correct (what you would do if you were doing a demo).
• Check out the due dates on the main repo for the course.

• Labo HTTP (1): Serveur apache httpd "dockerisé" servant du contenu statique

• You have a GitHub repo with everything needed to build the Docker image.
• You can do a demo, where you build the image, run a container and access content from a browser.
• You have used a nice looking web template, different from the one shown in the webcast.
• You are able to explain what you do in the Dockerfile.
• You are able to show where the apache config files are located (in a running container).
• You have documented your configuration in your report.

• Labo HTTP (2a): Application node "dockerisée"
• Labo HTTP (2b): Application express "dockerisée"

• You have a GitHub repo with everything needed to build the Docker image.
• You can do a demo, where you build the image, run a container and access content from a browser.
• You generate dynamic, random content and return a JSON payload to the client.
• You cannot return the same content as the webcast (you cannot return a list of people).
• You don't have to use express.js; if you want, you can use another JavaScript web framework or event another language.
• You have documented your configuration in your report.

• Labo HTTP (3a): reverse proxy apache httpd dans Docker
• Labo HTTP (3b): reverse proxy apache httpd dans Docker
• Labo HTTP (3c): reverse proxy apache httpd dans Docker

• You have a GitHub repo with everything needed to build the Docker image for the container.
• You can do a demo, where you start from an "empty" Docker environment (no container running) and where you start 3 containers: static server, dynamic server and reverse proxy; in the demo, you prove that the routing is done correctly by the reverse proxy.
• You can explain and prove that the static and dynamic servers cannot be reached directly (reverse proxy is a single entry point in the infra).
• You are able to explain why the static configuration is fragile and needs to be improved.
• You have documented your configuration in your report.

• Labo HTTP (4): AJAX avec JQuery

• You have a GitHub repo with everything needed to build the various images.
• You can do a complete, end-to-end demonstration: the web page is dynamically updated every few seconds (with the data coming from the dynamic backend).
• You are able to prove that AJAX requests are sent by the browser and you can show the content of th responses.
• You are able to explain why your demo would not work without a reverse proxy (because of a security restriction).
• You have documented your configuration in your report.

• Labo HTTP (5a): configuration dynamique du reverse proxy
• Labo HTTP (5b): configuration dynamique du reverse proxy
• Labo HTTP (5c): configuration dynamique du reverse proxy
• Labo HTTP (5d): configuration dynamique du reverse proxy
• Labo HTTP (5e): configuration dynamique du reverse proxy

• You have a GitHub repo with everything needed to build the various images.
• You have found a way to replace the static configuration of the reverse proxy (hard-coded IP adresses) with a dynamic configuration.
• You may use the approach presented in the webcast (environment variables and PHP script executed when the reverse proxy container is started), or you may use another approach. The requirement is that you should not have to rebuild the reverse proxy Docker image when the IP addresses of the servers change.
• You are able to do an end-to-end demo with a well-prepared scenario. Make sure that you can demonstrate that everything works fine when the IP addresses change!
• You are able to explain how you have implemented the solution and walk us through the configuration and the code.
• You have documented your configuration in your report.

• You extend the reverse proxy configuration to support load balancing.
• You show that you can have multiple static server nodes and multiple dynamic server nodes.
• You prove that the load balancer can distribute HTTP requests between these nodes.
• You have documented your configuration and your validation procedure in your report.

• You do a setup to demonstrate the notion of sticky session.
• You prove that your load balancer can distribute HTTP requests in a round-robin fashion to the dynamic server nodes (because there is no state).
• You prove that your load balancer can handle sticky sessions when forwarding HTTP requests to the static server nodes.
• You have documented your configuration and your validation procedure in your report.

• You develop a solution, where the server nodes (static and dynamic) can appear or disappear at any time.
• You show that the load balancer is dynamically updated to reflect the state of the cluster.
• You describe your approach (are you implementing a discovery protocol based on UDP multicast? are you using a tool such as serf?)
• You have documented your configuration and your validation procedure in your report.

• You develop a web app (e.g. with express.js) that administrators can use to monitor and update your web infrastructure.
• You find a way to control your Docker environment (list containers, start/stop containers, etc.) from the web app. For instance, you use the Dockerode npm module (or another Docker client library, in any of the supported languages).
• You have documented your configuration and your validation procedure in your report.