All the pathes lead to Docker(Con)

DockerCon Europe 17 is already behind us, and I would like to share my path that lead me to attend it. The journey was by far not a straight line and it could even provide with some ideas on how to request your travel next year.

How it all started

It all starts with an anecdote that I was lucky enough to share with the ‘main victim’ during DockerCon:

Around 2 years ago, my Geek team decide to try learn Go(lang). The community was quite already in place and howtos, videos training and examples were already massively available.
Still, for whatever reason we ended downloading a pirated copy of a certain Nigel Poulton Go course.
We simply became instant fans of both the person and the language. However, during his course he kept mentioning how Go was production ready because it already was the power behind Docker, this “new” container technology that was taking the world by storm.

As I always try to give back to Caesar when possible, I managed to have my company ordering me a 1 year Pluralsight license (sorry for the initial steal) and when I looked up on the training Mr Poulton created, there was already 3 of them about Docker (fun fact: the Docker Learning Path can be called the Nigel Path to Docker wisdom as only his courses are listed).

While I was seeing a lot of potential in Docker, being in a company that runs exclusively Microsoft technology and applications based, the sell was kinda difficult at first.
Hopefully for me, with Microsoft’s new direction and vision under Satya Nadella, the wait was not long and Microsoft embraced the Docker train instead of creating a similar (and compatible) technology.
I could then make a first presentation of this technology to my CIO and he simply was mind blown about this technology.

The next logic step was to know more about Docker in the industry (Pharmaceuticals if possible) and DockerCon seemed the right place to do so, as I knew there would be Customer success stories and certainly could learn about best practices for implementing it.

My CIO approved, however as I am part of the Business Applications team, he told me that I would get his sponsorship only if someone from the IT Operations would join me.
Side note: for the ones who attended Lee Namba‘s talk (MTA with Docker EE: From PoC to Production) my journey at that point was already in the pit. I didn’t even had the luxury to rejoice at the top of the initial curve.

After few discussions with the Head of Deployement, he appointed one of his direct reports to go with me and that’s how I finally ended in DockerCon.

There is still much to say, however I would prefer discuss it live around a good burger.

My final words/advice on this journey would be: your Docker journey can start in many ways, but it will (hopefully) always end in one of the greatest communities I’ve seen in a long time.
I have four words for you: Welcome to Docker(Con), Friend!

>>> Nunix out <<<

WSL & VSCode: Feeling at $home

In my previous blog, the plugin used to be able to modify files in the WSL filesystem without corruption was allowing only 1 file to be modified and “seen” in VSCode.
I’m glad to say that I finally found another plugin that not only provides the same SSH support (avoiding files corruption as stated above) but also provides a more complete “dev experience”.

Before we start, there is 2 prerequisites for this solution to work:

  • You should have a working OpenSSH server in your WSL environment.
    There is quite a lot of help or guides in Internet, but so far the “full solution” that is working all the time for me is the answer of this post
  • The VSCode console should be your WSL shell instead of Powershell (not mandatory, but more user friendly).
    You can change your user-settings (CTRL+,) with the following line for Ubuntu flavour:

    “terminal.integrated.shell.windows”: “C:\\Users\\<Your Username>\\AppData\\Local\\Microsoft\\WindowsApps\\ubuntu.exe”

Here is a quick how-to for the setup:

  1. Install VSCode and/or VSCode-Insiders (used for my demo)
  2. Install the plugin “FTP-Simple”
  3. Open the command bar (CTRL+SHIFT+P) and search for ftp-simple: config
  4. Create a first basic configuration just to ensure everything is working fine
  5. Open the command bar (CTRL+SHIFT+P) and search for ftp-simple: Remote directory to Workspace
  6. Choose your connection according to the name you provided in step 4
  7. [Optional] If you didn’t insert the password, type the password to the WSL account
  8. Choose from where the initial path should be open
  9. The workspace should be now open with the files and directories from the path you provided in step 4
  10. Open the terminal in VSCode
  11. Try changing content from Code or directly from the Console

Last (random) comments

  • This solution does not work with a separated terminal opened. The Workspace of VSCode keeps the SFTP connection alive, that’s what allow us to directly modify the files without having a new VSCode window being open
  • Your initial directory is the new ‘/’. You can think of it as a ‘chroot’. This means that if you try to open a file that is ‘below’ your initial directory, it will not work
  • Microsoft is working hard on bringing full interopability between WSL and Windows applications (filesystem included). So consider this post to be obsolete in the (near?) future.
  • The SSH solution is not my idea and it’s just an adaptation of Microsoft own solution for C++ and WSL.

Happy coding in your brand new WSL-VSCode environment.

WSL: Edit files remotely

So, after the (very) impressive demo by @richturn_ms during the Windows Developer Day – Creators Update, for the ones following WSL since some time now (if not from the beginning), there was this part that must have triggered the “wow” effect.

Now, I’m by no means what you can call a developer. Matter fact, I’m not a SysAdmin neither, just a simple hobbyist who likes to come with “special” ideas.

Back to our topic, after the “wow” effect faded away, I scratched my head a little bit as Rich was showing something that was normally forbidden!
Or was he? the way he performed the demo, was actually the “correct” way: from one OS to another using a standard protocol (SSH).

After some research, I found also a way for the ones of us that do not code in C++, however would like to modify files, directly from the WSL filesystem in the “correct” way also with VSCode (however, I guess other editors will also be able to apply this method).
So for the ones of you, who would like to open/create/update files with VSCode, just follow this small steps:

  1. Install Remote VSCode extension
  2. Edit your “User Settings” to enable the server to start automatically
  3. Bypass all the “SSH Tunneling” part, it will not be needed in our case
  4. Install Rmate for Bash (just perform the Quick Install commands)
  5. From WSL, run $ rmate -H localhost mytextfile.txt
  6. Save your changes, and confirm that the change has been correctly applied:
    • $ ll mytextfile.txt
    • $ cat mytextfile.txt

And that’s all, this should allow you to edit single files when following howtos in Internet (think Go, Nodejs, etc..).

>>> Nunix out <<<

WSL: mount drives the docker way

So, I have this shiny Surface Pro 4 with a nice 64Go SDCard and, as you may know if you’re reading this blog, WSL does not (yet) mount SDCards or USB sticks.

I tried two “normal” ways, with CIFS and SSHFS, however when trying to mount the filesystem I got the not so nice errors.

CIFS:

ref: https://www.swiftbyte.com/articles/linux/mounting-a-wicd bashhare-in-ubuntu-on-boot

SSHFS:

ref: https://www.digitalocean.com/community/tutorials/how-to-use-sshfs-to-mount-remote-file-systems-over-ssh

Then, while playing with Docker and the WSL, I could actually mount my SDCard to a docker (normal) and then access it from the “normal/linux” docker client:

Ok, until now, everything is working as expected. A quick inspect show us the configuration of the Mount:

At this moment, as my *nix skills are a bit rusty, I searched for an alternative to NFS as my direct memories are not so good, so don’t blame me but my Masta instead.
Also the high risk of not being able to mount it (once again) didn’t motivate me too much (still, I will try it in another blog if no one else tries it).

“Et la lumière fut!”. I already went to the extent of implementing an SSH server into a container (by the way, no need for that to access it) so I could try to RSYNC and … IT WORKED.

So here is the setup needed:

  1. Have Docker for Windows installed
  2. Pull the Ubuntu image (I choose this one for “standardization” purpose)
  3. Create a new container from Powershell! with the following options and follow the configuration stated in Docker own Dockerfile for the SSH service:
    PS> docker run -it -p 2222:22 -v d:/:/mnt ubuntu bash

    • The reason is simple: Powershell “sees” your external drive
    • This command will expose the SSH port to your local port 2222 and mount your external drive to “/mnt”
  4. Install RSYNC in the container
    $ apt-get install rsync

    • You can exit your session without killing your container by using “CTRL+P” and then type “CTRL+Q”
  5. Open a WSL Bash console
    • You can already connect with your WSL Docker client and see your drive mounted in “/mnt”
  6. Install RSYNC (if not already done) in WSL
    $ apt-get install rsync
  7. Try to sync a file from WSL to your External drive
    /usr/sbin/rsync -avh --progress -e "ssh -p2222" bigfile.txt root@192.168.192.55:/mnt/

    • Please note that you need your “local IP” as we did map the port 2222 to the ssh port of the Container
    • For this first test, I created a 1Go file and synched it

And here you have, now you can have your files synched to your external drives.
I will do a follow-up blog post with another synch tool: Unison (both ways sync for the win).

>>> Nunix out <<<

Welcome to Nunix.tech

After blogging sporadically on blogpost, I saw one offer for creating a blog site with a .tech domain.

I will try to blog at least once a month and the topics will continue to be the same: Windows (10) Subsystem for Linux WSL and Docker “client side”.

Last but not least, this is a blog from a simple hobbyist. I will always reference my sources for the ones of you who want to go deeper into the different topics.

So relax, enjoy the blog and if you pass by the very beautiful Switzerland (french part) let me know, we can always meet to discuss geeky stuff.

>>> Nunix out <<<