Menu

LXC Containers with Unicon

Jafar
2016-10-12
2017-08-31
  • Jafar

    Jafar - 2016-10-12

    I use LXC containers heavily these days, and I thought it would be great if I could add Unicon to the mix. I wrote a little library to do just that. You can find the code here:

    https://github.com/Jafaral/lxcunicon

    Still in an early stage, but I can do some basic operations like create/start/stop/freeze/unfreeze. I will continue to improve and add new features as I go. If anyone is interested in helping out or have ideas how to best do things in this arena please let me know.

    Cheers,
    Jafar

     

    Last edit: Jafar 2016-10-12
  • Brian Tiffin

    Brian Tiffin - 2016-10-14

    A good idiom for a library of functions in a class, thanks, Jafar.

    I was just about to razz you that LCX create didn't seem to build in a Unicon, now I see it's a chef recipe. Nice.

    Cheers,
    Brian

     
  • Jafar

    Jafar - 2016-10-14

    Brian,

    You should be able to create containers directlty from the library. Do you get errors if you run the sample program there? The script at the top level should prepare the environment (assumes ubuntu at the moment) to run container, unpriviliged ones. If you have any problems please let me know. I'm working on supporting issuing commands from the unicon program to be run inside the container.

    I added the Chef recipe for testing and convience but you don't need that at all. I will add more instrcutions on how to use that one as well. I added it to quickly build a machine with Unicon setup to serve as sanbox for quick isolated testing.

    Cheers,
    Jafar

     
    • Brian Tiffin

      Brian Tiffin - 2016-10-14

      creates work. booting up the container failed.

      I'm willing to bet it is a poorly configured local LXC infrastructure install (still have a few issues with unprivileged userland containers)

      $ unicon -s -t hellolxc.icn -x
                                :        main(list_1 = [])
      Initialize LXC library...
      hellolxc.icn              :     9  | LXC__LXC("./lxcunicon.so")
      __faux.icn                :     8  | | LXC__LXCinitialize()
      __faux.icn                :    18  | | LXC__LXCinitialize failed
      __faux.icn                :    12  | | LXC__LXC_initially(LXC__LXC_1,"./lxcunicon.so")
      lxcunicon.icn             :    78  | | LXC__LXC_initially returned &null
      __faux.icn                :    13  | LXC__LXC returned LXC__LXC_1
      hellolxc.icn              :    11  | LXC__LXC_Container(LXC__LXC_1,"uniconvm")
      lxcunicon.icn             :    34  | | LXC__LXContainer("uniconvm",&null,&null,&null,&null,&null)
      __faux.icn                :     8  | | | LXC__LXContainerinitialize()
      __faux.icn                :    18  | | | LXC__LXContainerinitialize failed
      __faux.icn                :    12  | | | LXC__LXContainer_initially(LXC__LXContainer_1)
      lxcunicon.icn             :   124  | | | | LXC__LXC_Arch(LXC__LXC_1)
      lxcunicon.icn             :    42  | | | | LXC__LXC_Arch returned (variable = "amd64")
      lxcunicon.icn             :   125  | | | LXC__LXContainer_initially returned &null
      __faux.icn                :    13  | | LXC__LXContainer returned LXC__LXContainer_1
      lxcunicon.icn             :    34  | LXC__LXC_Container returned LXC__LXContainer_1
      hellolxc.icn              :    13  | LXC__LXContainer_Exist(LXC__LXContainer_1)
      lxcunicon.icn             :    94  | LXC__LXContainer_Exist failed
      creating a container named uniconvm...
      hellolxc.icn              :    17  | LXC__LXContainer_Create(LXC__LXContainer_1,&null,&null,&null)
      lxcunicon.icn             :    91  | LXC__LXContainer_Create returned (variable = 1)
      booting uniconvm...
      hellolxc.icn              :    22  | LXC__LXContainer_Start(LXC__LXContainer_1)
      lxcunicon.icn             :    98  | LXC__LXContainer_Start failed
      couldn't do it
      

      Cheers,
      Brian

       
      • Jafar

        Jafar - 2016-10-15

        Ah, getting your first userland running might be tircky if this is the fisrt time you do it since you have to iron out some configuration details. That is why I wrote the script luxify.sh. To debug, I'd try to boot the container up from command line and see what happen.

        lxc-start -l DEBUG -F -n uniconvm
        

        -l DEBUG ramps up your logging level, and -F keeps eveything in the foreground (by default the container process is daemonized). You should be able to see what goes wrong there. The two main reasons that cause booting to fail is that your ~/.local directory needs to be marked as executabe (-x premession). The second reason is networking. Check /etc/lxc/lxc-usernet and make sure it has a line like this:
        $USER veth $BRDGNAME 50

        where user is your user name, and $BRDGNAME is lxc network bridge.

        Again, look at luxify.sh to get some clues on what to configure if you don't want to run the script itself.

        Once you get userland containers to run, you never look back! there is no reason to run them with root permissions for the vast majority of cases.

        Cheers,
        Jafar

         

        Last edit: Jafar 2017-08-31
        • Brian Tiffin

          Brian Tiffin - 2016-10-15

          Just needed the networking bridge config and the +x on ~/.local.

          $ ./hellolxc
          Initialize LXC library...
          creating a container named uniconvm...
          booting uniconvm...
          loop for 20 seconds report the state every 5 seconds
          uniconvm is "RUNNING"
          uniconvm is "RUNNING"
          uniconvm is "RUNNING"
          uniconvm is "RUNNING"
          uniconvm is "STOPPED"
          Time for cleanup, destroying uniconvm
          All OK, Goodbye!
          

          :-)

          Cheers,
          Brian

           
          • Jafar

            Jafar - 2016-10-15

            Cool! Now we just need an "attach" method to run any command inside the
            container on the fly!

             
  • Jafar

    Jafar - 2016-10-16

    You can now send coammnds to be run inside the container via the new container method: Attach(). Here is a code snippet with output:

       write("run some commands inside ", name)
       cmds := ["uname",
                "uname -a",
                "uname -r" ,
                "hostname",
                "whoami",
                "pwd",
                "apt-get install htop"]
       every writes(left(cmd:=!cmds, 12), ": ") & c.Attach(cmd)
    

    And the output:

    run some commands inside uniconvm
    uname       : Linux
    uname -a    : Linux uniconvm 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
    uname -r    : 4.4.0-21-generic
    hostname    : uniconvm
    whoami      : root
    pwd         : /
    Reading package lists... Done
    Building dependency tree       
    Reading state information... Done
    htop is already the newest version (2.0.1-1ubuntu1).
    0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
    
     
    • Brian Tiffin

      Brian Tiffin - 2016-10-17

      I think lxcunicon.c needs to be commited to the github space; the copy I see has no attach function defined. Figured out most of the rest just by guessing, before looking at your repository, but I'm not sure how to define the attach in C code.

      Cheers,
      Brian

       
      • Jafar

        Jafar - 2016-10-17

        Ahh! I missed to commit that one.... but I just did. Thanks for catching it.

        My next step is I/O redirection when issuing commands via Attach(). Stay tuned!

        Cheers,
        Jafar

         
        • Brian Tiffin

          Brian Tiffin - 2016-10-17

          Worked the charm

          prompt$ unicon -s hellolxc.icn -x
          
          Initialize LXC library...
          container uniconvm already exists
          booting uniconvm...
          run some commands inside uniconvm
          uname       : Linux
          uname -a    : Linux uniconvm 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12 13:48:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
          uname -r    : 4.4.0-43-generic
          hostname    : uniconvm
          whoami      : root
          pwd         : /
          Reading package lists... Done
          Building dependency tree
          Reading state information... Done
          Suggested packages:
            lsof strace
          The following NEW packages will be installed:
            htop
          0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
          Need to get 76.4 kB of archives.
          After this operation, 215 kB of additional disk space will be used.
          Get:1 http://archive.ubuntu.com/ubuntu xenial-updates/universe amd64 htop amd64 2.0.1-1ubuntu1 [76.4 kB]
          Fetched 76.4 kB in 0s (159 kB/s)
          Selecting previously unselected package htop.
          (Reading database ... 13019 files and directories currently installed.)
          Preparing to unpack .../htop_2.0.1-1ubuntu1_amd64.deb ...
          Unpacking htop (2.0.1-1ubuntu1) ...
          Processing triggers for mime-support (3.59ubuntu1) ...
          Setting up htop (2.0.1-1ubuntu1) ...
          loop for 20 seconds report the state every 5 seconds
          uniconvm is "RUNNING"
          uniconvm is "RUNNING"
          uniconvm is "RUNNING"
          uniconvm is "RUNNING"
          uniconvm is "STOPPED"
          All OK, Goodbye!
          

          Nice add, Jafar.

           
          • Jafar

            Jafar - 2016-10-17

            Thanks Brian. Good to see my experimental code working at your end.
            I just added support for IO redirection. Things are slowly getting to the point where this could be useful and all run from Unicon :-)

             
            • Brian Tiffin

              Brian Tiffin - 2016-10-17

              Kudos. Yes it could come in handy, Jafar.

              I was working with Canonical a few years back, to demonstrate GnuCOBOL as a JuJu Charm (Ubuntu Cloud). This is the kind of effort that could make for an easy to wield demo of Unicon in the Cloud. Tap a browser icon, and away you go.

              Full disclosure, I think the cloud is a gold rush; a few rare few will make millions/billions, most people will struggle up the mountain, spend 10 years working very hard, to realize they made just enough money to buy a coach ticket home, and then entire towns will be laid waste once the rush is over. But that is personal opinion, and most people seem quite happy to pay the bills that are making a few more billionaires.

              It was pretty cool though. At the time I was running Fedora; used a libvirt virtual image of Ubuntu, to run a local JuJu charm cloud instance, that spun off another OS image, to compile a version of GnuCOBOL and host some CGI programs. A screen shot is part of the GnuCOBOL FAQ, http://open-cobol.sourceforge.net/faq/index.html#can-gnucobol-be-used-for-cgi

              I barely finished the demo, and then realized that people were getting sucked into the cloud and burning money they shouldn't be burning...

              https://jujucharms.com/u/bwtiffin/gnucobol-sample

              Local Containers seem like a much more human friendly endeavour. :-)

              Have good, make well,
              Brian

               
  • Charles Evans

    Charles Evans - 2017-08-31

    On ubuntu Zesty 64,
    luxify.sh :
    systemd-services # does not exist
    We have systemd-container and 11 more.
    systemd-container has nspawn.
    I forgot where it was before.
    What does one need from systemd-services?

     
    • Jafar

      Jafar - 2017-08-31

      When I first created this script on Ubuntu 14.04 there were many missing packages that you need to get going. With 16.04 the list is a lost shorter and my script is probably an overkill. You might be Ok to move on without systemd-services. Did you try creating a container after runing the script?

       
  • Jafar

    Jafar - 2017-08-31

    BTW, lxcunicon is now included with unicon sources under plugins/src. There is a sample program under plugins/src/lxcunicon/tests. plugins/lib is now one of the standard/default locations for adding new loadbale modules. So if you build lxcunicon you should be able to use lxcunicon (.so and .u files) from anywhere on your machine without specifying absolute paths.

    In the last few nights I have been working on a Unicon program that lanuches containers of different platforms (ubuntu/fedora/centos/debian... i386/amd64). It then checkout, build and test Unicon on each and every container and generate a report for each one. I'm planning to run that as a nightly task on one of my machines and have the test reports available for developers/public. I might check in the program itself under unicon/tests somewhere..

     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.