Learn about different ways you can use Hyper-V to run Linux containers on Windows as if they're native.
rDod can be launch as it but you might want to customize. To do so, a few environment variables are available such as :
If you are using docker-compose you can also edit the docker-compose file to customize rDod
rDod cab be launch by 2 different ways :
Docker-Compose is the easiest way to launch rDoD. By using it the Home of the rDod user will be persistent.
You can use Docker-Compose to download and launch rDoD by using the following command:
docker-compose up
It's also possible to launch rDoD in "detach" mode by adding the -d parameter:
docker-compose up -d
You can launch rDoD by using the classical Docker CLI. That way permit a better customization but will require to write a longer command line.
docker run -p 5901:5901 -p 5911:5911 mderasse/rdod:latest
Of course you can replace latest by another image tag.
You might also want to have a persistent Home. You can do this by using the parameter -v like :
docker run -p 5901:5901 -p 5911:5911 -v $(pwd)/home:/home/user mderasse/rdod:latest
You might also want to use those parameter :
rDoD currently provide 2 different ways of access.
In order to acces to rDoD by using VNC you will have to install the TigerVNC viewer.
You can find the different binary depending of your OS on that link: TigerVNC Viewer
After the installation done you will have to launch the client and connect to :
YOUR_IP:5901
noVNC is a HTML5 Client. You can access it directly by using your favorite Web Browser
http://YOUR_IP:5911
Don't forget to change HTTP to HTTPS is USE_SSL is enabled.
rDoD is made in a way that it's really easy to extend it.
Do to so you will have to create a Dockerfile like the following one:
FROM mderasse/rdod:latest
LABEL maintainer="Matthieu DERASSE <github@derasse.fr>"
# Back to Root
USER 0
# Configure Custom System
COPY ....
RUN ....
# Back to User
USER 1000
Please, take a look at the customs directory, that can be a good source of inspiration. Feel free to share your version by creating a pull Request!
1) noVNC does not handle well all the keyboard key
A plain docker environment for building static binaries compiled with rust and linked against musl instead of glibc. Built nightly on travis.
This is only useful if you require external C dependencies, because otherwise you could do rustup target add x86_64-unknown-linux-musl.
This container comes with a bunch of statically compiled C libraries using musl-gcc so that we can statically link against these as well.
If you already have rustup installed on the machine that should compile, you might consider cross as a more general solution for cross compiling rust binaries.
Usage
Pull and run from a rust project root:
docker pull clux/muslrust
docker run -v $PWD:/volume --rm -t clux/muslrust cargo build
You should have a static executable in the target folder:
ldd target/x86_64-unknown-linux-musl/debug/EXECUTABLE
not a dynamic executable
From there on, you can include it in a blank docker image (because everything you need is included in the binary) and perhaps end up with a 5MB docker blog image.
Build Docker Images for ARM hosts on Intel
docker run -v /usr/bin/qemu-arm-static:/usr/bin/qemu-arm-static --rm -ti armhf/alpine
enjoy !
(pratique pour faire de la cross compilation, en fait pas vraiment c'est plus de l'emulation pour compiler...)
docker run --name=domoticzjosh \
--privileged \
--cidfile="cid" \
-d \
-p 8080:8080 \
-p 6144:6144 \
-t joshuacox/mkdomoticz
Get Singularity Open-Source Singularity Open-Source follows the “release early, release often” principle and contains the latest and the greatest of all the new code contributed to Singularity. More details in our mission statement. GitHub repository Releases Documentation Join Community Report a bug We are open-source enthusiasts like you! All features, development and advances to our …
Cross compiling toolchains in Docker images
Et pour être root :
docker exec -it --user root
Create a systemd drop-in directory for the docker service:
$ mkdir -p /etc/systemd/system/docker.service.d
Create a file called /etc/systemd/system/docker.service.d/http-proxy.conf that adds the HTTP_PROXY environment variable:
[Service]
Environment="HTTP_PROXY=http://proxy.example.com:80/"
Or, if you are behind an HTTPS proxy server, create a file called /etc/systemd/system/docker.service.d/https-proxy.conf that adds the HTTPS_PROXY environment variable:
[Service]
Environment="HTTPS_PROXY=https://proxy.example.com:443/"
If you have internal Docker registries that you need to contact without proxying you can specify them via the NO_PROXY environment variable:
Environment="HTTP_PROXY=http://proxy.example.com:80/" "NO_PROXY=localhost,127.0.0.1,docker-registry.somecorporation.com"
lush changes:
$ sudo systemctl daemon-reload
Restart Docker:
$ sudo systemctl restart docker
Verify that the configuration has been loaded:
$ systemctl show --property=Environment docker
Tutoriel sur l'utilisation de LXC (je teste Docker mais LXC semble plus apte à remplir mes exigences...)
Each
ADD hom* /mydir/ # adds all files starting with "hom"
ADD hom?.txt /mydir/ # ? is replaced with any single character, e.g., "home.txt"
The
ADD test relativeDir/ # adds "test" to `WORKDIR`/relativeDir/
ADD test /absoluteDir/ # adds "test" to /absoluteDir/
If
docker run -a stdin -a stdout -i -t debian-sshd /bin/bash
Si vous utilisez docker vous avez surement remarqué que l'espace disque utilisé augmente rapidement. Voici quelques règles pour économiser un peu de place sur votre disque.
Supprimer les volumes associés à un conteneur
Lorsqu'on supprime un conteneur penser à utiliser l'option -v qui permet de supprimer les volumes associés à un conteneur.
Pour supprimer tous les conteneurs qui ne tournent pas on peut utiliser la commande suivante:
docker rm -v $(docker ps -aqf status=exited)
Recréé un conteneur est assez rapide du moment que son image est disponible. Ce qui nous amène vers le nettoyage des images inutiles.
Supprimer les images inutiles
J'appelle image "inutile" une image "intermédiaire" qui sert dans la construction d'une image "finale" et qui n'est donc jamais utilisé pour créer un conteneur.
On peut supprimer ces images avec la commande suivante:
docker rmi $(docker images -qf dangling=true)
Souvent indispensable après un docker pull.
Supprimer les volumes orphelins
Un volume orphelin est un volume pour lequel son conteneur associé a été supprimé sans l'option -v. Pour supprimer ces volumes on a la commande suivante:
docker volume rm $(docker volume ls -qf dangling=true)
Ok, utilisons un volume
Maintenant que vous avez compris le principe, sachez que docker peut vous permettre de créer un volume sans passer par un conteneur. C’est là que je veux en venir !
Prenons un exemple que j’utilise beaucoup, un conteneur mongo dont je ne veux pas perdre les données. J’utilisais, avant, un répertoire perso pour y stocker les données.
Plus tard, j’ai utilisé un conteneur data-only, ce qui fonctionne bien, je ne dis pas le contraire. L’image mongo déclare un volume “/data/db”, donc je n’avais qu’à faire:
docker run --name mongodata -v /data/db -it -d busybox
docker run --rm -it --volumes-from mongodata mongo
Oui, mais c’est bête !
Voilà la meilleure façon de faire:
docker volume create --name mongodata
docker run --rm -it -v mongodata:/data/db mongo
Cette fois, je définis où je monte le volume, et je n’ai qu’un seul conteneur qui tourne: le conteneur mongo. Le volume est local (par défaut) et se trouve ici:
$ docker volume inspect mongodata
[
{
"Name": "mongodata",
"Driver": "local",
"Mountpoint": "/var/lib/docker/volumes/mongodata/_data"
}
]
C’est bien plus efficace et ça limite largement le nombre de conteneurs à démarrer. On notera aussi la facilité à retrouver les volumes par leurs noms.
pour aller plus loin: https://docs.docker.com/engine/tutorials/dockervolumes/