Nous recrutons un·e ingénieur·e en informatique pour travailler à l’application des concepts et technologies DevOps (conteneurs Docker, Git, Linux, libre, …) pour la mise au point et l’hébergement de dispositifs de Travaux Pratiques virtualisés, qui seront utilisés pour des enseignements d’informatique et de réseaux, sur un CDD de 1 an, à Télécom SudParis, à Évry (91).
Pour en savoir plus, voir le descriptif du poste que j’ai mis en ligne.
I’ve improved a bit the org-teaching framework in order to prepare for the next edition of the CSC4101 classes.
I’ve now added a docker container which is in charge of performing the HTML or PDF exports of the slides (using org-reveal) or handbooks (using LaTeX).
Emacs and org-mode are still advised for editing contents, but having this container in the loop ensures that colleagues are able to preview the changes to the teaching material, and I’m no longer a bottleneck for generating the handouts. This also allows to export in a reproducible way, which doesn’t depend on my Emacs config tweaks.
I’ve also added Gitlab pages to the project’s CI so that the docs are updated live at https://olberger.gitlab.io/org-teaching/.
It’s probably not yet rady for use by anyone else, but I’d be glad to get feedback 😉
During the course of Web architecture and applications, our students had to deliver a Silex / Symfony Web app project which I’m grading.
I had initially hacked a Docker container to be able to test that the course’s lab examples and code bases provided would be compatible with PHP 5 even though the nominal environment provided in the lab rooms was PHP 7. As I’m running a recent Debian distro with PHP 7 as the default PHP installation, being able to run PHP 5 in a container is quite handy for me. Yes, PHP 5 is dead, but some students might still have remaining installs of old Ubuntus where PHP5 was the norm. As the course was based on Symfony and Silex and these would run as well on PHP 5 or 7 (provided we configured the right stuff in the composer.json), this was supposed to be perfect.
I’ve used such a container a lot for preparing the labs and it served me well. Most of the time I’ve used it to start the PHP command line interpreter from the current dir to start the embedded Web server with “php -S”, which is the standard way to run programs in dev/tests environment with Silex or Symfony (yes, Symfony requires something like “php -S localthost:8000 -t web/” maybe).
I’ve later discovered an additional benefit of using such a container, when comes the time to grad the work that our students have submitted, and I need to test their code. Of course, it ensures that I may run it even if they used PHP5 and I rely on PHP 7 on my machine. But it also assures that I’m only at risk of trashing stuff in the current directory if sh*t happens. Of course, no student would dare deliver malicious PHP code trying to mess with my files… but better safe than sorry. If the contents of the container is trashed, I’m rather on the safe side.
Of course one may give a grade only by reading the students’ code and not testing, but that would be bad taste. And yes, there are probably ways to escape the container safety net in PHP… but I sould maybe not tempt the smartest students of mine in continuing on this path 😉
If you feel like testing the container, I’ve uploaded the necessary bits to a public repo : https://gitlab.com/olberger/local-php5-sqlite-debian.
I’ve documented the process of installing a Docker Swarm cluster inside VirtualBox with Docker Machine. This allows experimenting with Docker Swarm, the simple docker container orchestrator, over VirtualBox.
This allows you to play with orchestration scenarii without having to install docker on real machines.
Also, such an environment may be handy for teaching if you don’t want to install docker on the lab’s host. Installing the docker engine on Linux hosts for unprivileged users requires some care (refer to docs about securing Docker), as the default configuration may allow learners to easily gain root privileges (which may or not be desired).
See more at http://www-public.telecom-sudparis.eu/~berger_o/docker/install-docker-machine-virtualbox.html
I’ve been working on setting up a Docker container environment allowing to test the RuneStone Interactive server.
That’s the part which I wanted to be able to operate for test purposes. As it is a
web2py application, it’s not exactly obvious to gather all dependencies and run locally. Well, in fact it is, but I want to understand the architecture of the tool to be able to understand the deployment constraints, so making a docker image will help in this purpose.
The result is the following :
Now, it’s easier to test the writing of a new course (yet another container above the latter one), and directly test for real.