 Hello everyone and welcome to the 8.30 to 9 o'clock session of the 2019 Open Simulator Community Conference. In this session, we are happy to introduce a presentation called Dockerizing Open Simulator. Our speaker is Mr. Blue Waves, aka Robert Adams. Please check out the website found at conference.opensimulator.org for speaker bios, details of the sessions as well as the full schedule of events. And I'm going to paste this in here so you have a little bit of a bio as I'm telling you about him and his website. Robert Adams has been an Open Simulator core developer for OpenSim for many years. His Open Simulator work includes the BulletSim physics engine, the DSG, which is Distributed Scene Graph Simulator experiment and many performance improvements. Outside Open Simulator, he has been a computer developer and researcher for 40 years. He has a current interest in distributed simulation and robotics. Today he will be talking with us about adapting Open Simulator for deployment using Docker, using Open Simulator, single containers and multiple containers, simulator and database, whether in stand alone or in grid mode. For more information on his work, please see the website MrBlue.com. This session is being live streamed and recorded. So if you have any questions or comments during this session, you may send your tweets to at OpenSimCC and please use the hashtag pound OSCC19. Welcome everyone and let's begin the session. Hello all. I'm Robert Adams and I'm here to talk to you about using Docker and Open Simulator. So what I'll do in the next 20 minutes is I'll take a few minutes to talk about what Docker is and then I'll talk about a few minutes about what the configuration is that I set up and then I'll take a few minutes talking about how I configured Open Simulator for running under Docker and then there'll be time for questions hopefully. And if there's not time for questions, I have a speaker booth over in the expo zone 3 which I will be hanging out at so you can ask me questions there. So the particular thing about running things in Docker is Docker came from, in Linux, there's a whole bunch of different technologies about isolating applications. So there was, if you've ever run Linux, you knew about charoot where you could change the root of a application so that they couldn't get out and access other files. And over years those isolation technologies got more and more complex until you could almost simulate a complete virtual machine. And so these isolation technologies were packaged in several different container systems. So from a user's point of view, it looks like you're creating a virtual machine that is an environment where your application could run with all its dependencies and not touch anything else on the system. And these systems, there are several of them that exist. Docker is one, there's a one called Rocket, there's an LXC system, there's Mesos. And so you can go out and find all these different systems. But all in all Docker is the most popular one of container systems. And it essentially gives you a lightweight virtual machine. So rather than spinning up a whole hardcore virtual machine, you are just running a contained environment outside an existing operating system. And so all these, and all these different packaging container systems contain all the tools for creating these different containers, for deploying them into multiple sessions, and for configuring them. But I'm just going to focus on Docker because like I said, it's one of the more popular ones. So why would you containerize? Well, one of the nice things about the containers is you contain all the dependencies. That is once you can build an image for a container, you have solved all the problems of getting all the right versions in. So some of the people, sometimes you may have run open simulator and the OS has the wrong version of mono on it because there's another application that needed mono. So this allows you to build an open simulator with the version of mono that it used or the version of whatever library it is. You can also, they're also good for sharing. That is, once you build a container, you can share it with other people. That is the image that is so it's like sharing binary, you lean someone else use a binary, but now the binary is all packaged together with all its dependencies and everything else. For the operating system, for the distributed system people, deployment becomes easy because now if you need three copies of a web server or a web backend, you can just spin up three copies because you have these containers that you can run. And also it, one of the nice things about it is that these systems usually have definition files, that is, you have to define how you build a container. So it actually captures the build and runtime process and all the little steps in it. So a quick overview. I'll teach you everything about Docker in one minute. Docker has this conception of images. And images is, you can think of it as a bootable disk image. So it has an OS operating system interface, whether that's Linux or CentOS or Alpine or whatever base Linux-ish system you want. And then you build your image using the definition file called the Docker file. And the Docker file says everything that needs to be in this image, what files to put in it. So you can put in configuration files and set up the user environment. So it's like building a whole Linux system from scratch for your application. One of the interesting features of these images is they're built in layers. That is, there's different, you can think of things laid on top of each other. So for OpenSimulator, what I did was I started with a layer that's available for mono. So I just said, you start with the mono version six layer and build OpenSimulator, build OpenSimulator and then do the configuration for it. There are, Docker has a hub where you can get different images of people shared. So if you wanted to build an engine X based web server, you just start with that image and put your stuff on it and create your new image. So you take these images and you run them in containers. So after you've built the image, you just say Docker run the image name and it'll run that image, you know, spins it up in a container. And then after that, you manage the container. So that's like building a virtual machine and running it. And then there's service definition, what I call service definition. One of the features that most people use with Docker is, you know, it gets into the microservices and web, internet, distributed computing world, you can define different parts, different containers that need to talk to each other. So like in this case, as I'll show you, we have a, I have a MySQL server, a MariahDB server that the OpenSimulator talks to. And you start these up with a distributed service manager. Docker comes with Swarm, which is its little distributed service manager. One of the popular ones on the internet is Kubernetes, which is the big more real business oriented one. So here's a quick picture of what I built for OpenSimulator. So what you see here is two containers. There's an OpenSimulator talks to MariahDB. And it, so there's two containers. So first of all, there's the Docker environment. So Docker runs in an environment and you can install it on your if you have an individual Linux system, you install the Docker environment to run. It's available on most Linux systems. It's available on macOS. It's available in ARM. It's available for Windows 10. You can run these on your Windows system if you wish. Then they're also available in the cloud. That is all of the major cloud things, digital ocean, AWS, Google Cloud. They all have Docker environments that you can, if you get an image and build a container, you can just run it there. The OpenSimulator is, I started with Mono 5. Actually, I started moved to Mono 6, the latest thing. So I just, the OpenSimulator image is defined by there's a Docker file that says start with Mono 6, add the user OpenSim, download all the sources, build them, and then configure them for the base information. So you just build that image. The Mono DB, or the Maria DB that I'm using, is just one from the Docker hub. I didn't have to do anything to it. I just say start that up. Then I use Docker swarm, which uses a command Docker compose, which defines the fact that there are two containers. They talk to each other. The Docker swarm environment automatically creates a VPN for these pair of dockers to run in. So their communication is even secure in this setup. Then another thing that you specify is what the connections are to the outside world. In this case, I define that the Maria DB, actual DB files are outside the container environment. That has the nice feature that if you take down the containers and bring them up again, they will have persistent state, which means your region will still be there at the same time. And also you specify the connections to the outside world. That is normally within this VPN, no one could get to it. But in this case, I open up the port so the viewers can get to the open simulator. So this creates a pretty secure enclosed environment with defined connections to the outside world. So the project, all the files for this are on GitHub. You can follow this link and to find it. So it includes the scripts for building the open simulator image that is the Docker file. It includes its scripts for starting the Docker containers. So there's little run scripts that show you which commands to run that sort of stuff. There's scripts for the initial setup of open simulator. So once you build the image, the first time you run it, it has to initialize the database. It has to set up an estate manager and do all sorts of stuff. So it has those scripts. It has files for the operational configuration. So there's little scripts for taking your parameters like your external host name or your database password and initializing the region's any file and all those files. And then it has scripts for supporting the open simulator operation. That is, once open simulator is up, it'll run. You have to rotate the log files. You have to, if it crashes, you have to restart it. And it has all scripts for those. So as to configure an open simulator itself, is once you build the image and you want to run an open simulator, as anyone who's run an open simulator knows, there's a lot of configuration has to happen. So what I wanted to do was I wanted to have multiple region configurations embedded in the image. So like I could create an image for three or four regions and then run that image several times. I needed a way to kind of completely replace the open sim configuration. That is, I wanted it to all be able to just switch it out. If I had an installation, I wanted to use the image on. So I rejiggered the open simulator configuration by just using the existing open sim defaults and open sim in that is all the settings that are usually there. I knowled out all any any files and config include. And then I used the feature of open simulator that reads all any files in the directory bin config. That's a feature that most people don't use, but it's really nice in that since it reads all the any files, you can just put anything there you want and it'll work. And so you can completely replace the configuration by replacing what's in bin config or you can use what's there in the image. It runs open simulators that is the image is built to run start. It creates a user called open sim and then it starts running open sim boot open sim, which runs a setup file in the config file, does said on all the any files and then starts open simulator using screen. So it kind of works as an independent server all by itself. So this small print that you probably can't read is kind of all the steps that is you just you fetch the get image, you build the image, you have to do all the configuration that you normally have to do to an open sim simulator, and then you just run it. So you say run and it'll deploy the two things and run them and connect them together and run them by themselves. So this is my last slide. So the difficulties I had, like I mentioned, is configuration. This configuration is complex that is, you know, like region port numbers have to occur both in the region, any file and in the that connection to the outside world. And but what I want to do in the future is capture some package configurations. That is how we can do robust. There should be a configuration for building multiple servers. That is not only the simulator, but a robust server separate from it and the DB server. So there can be three containers running together. There could you could even package the management interface with it that is have a container started up with a web server and provide all the connections for that. And so I'm hoping that people out there will come to my open source repository and supply some pull requests for adding some of these other images. And we can capture pictures of standard configurations for MOPEN simulator for everyone to use. And that's the end of my presentation. And I'm open for questions. Yep. Do we have any questions? If you do, please put them in local chat. And thanks for providing that as open source that really helps a lot for people. Okay, John, see if we have any questions. Do we have any from before? Interesting progress, Lisa's mentioning. Well, and people will have questions when they try to do this in it. Yeah, that'll probably be the case. And but is there a place on the GitHub for them to put their feedback and things like that? Yes, there's a there's a well, a normal GitHub project will have an issue section. You can put in an issue section. If you have updates for yourself, you can add pull requests, which I would integrate into the project. So github.com slash Mr. Blue slash open sim. Make sure I didn't mis-type anything there. Hopefully that's the right link. Let's see. Yep, it looks like it gets there. Okay. So we got the link there. Well, okay. So it looks like things went well. Thanks for your presentation. Mr. Blue is very a very good presentation and we appreciate the work that you're doing. As a reminder to our audience, you can see what's coming up on the conference schedule at conference dot open simulator dot org. So following this session, the next session is not going to begin until 9 30 am in this keynote region and it's entitled Guinevere, learn a language through games and virtual worlds. Also, we encourage you to visit OSCC 19 poster expo in the OSCC expo three region. There you can find accompanying information on presentations, plus you can explore the hyper red tour resources, which are located in OSCC expo two region, along with the sponsor and crowd funder boots located throughout all the OSCC expo regions. Thank you again to our speaker.