TP1 done
This commit is contained in:
parent
a75f4b43b7
commit
5f4880dc50
Binary file not shown.
|
|
@ -2,30 +2,24 @@ Projet
|
|||
======
|
||||
|
||||
Pour mettre en pratiques toutes les notions que l'on a vu jusque là, écrivez un
|
||||
script `mycloud-run.sh` pour automatiser le lancement de votre instance
|
||||
personnelle de [`nextcloud`](https://hub.docker.com/_/nextcloud/) ou
|
||||
playbook Ansible pour automatiser le lancement de votre instance personnelle de
|
||||
[`nextcloud`](https://hub.docker.com/_/nextcloud/) ou
|
||||
d'[`owncloud`](https://hub.docker.com/r/owncloud/server/). Une attention
|
||||
particulière devra être apportée à la manière dont vous gérerez le rappel du
|
||||
script pour éventuellement relancer un conteneur qui se serait arrêté
|
||||
(évidemment sans perdre les données).
|
||||
particulière devra être apportée à la manière dont vous faites persister les
|
||||
données entre deux lancements, tout en prenant en compte les futures mises à
|
||||
jour.
|
||||
|
||||
À la fin de son exécution, le script affichera un lien utilisable sur l'hôte
|
||||
pour se rendre sur la page de connexion. Une autre machine de votre réseau
|
||||
local devrait également pouvoir accéder à la plate-forme, simplement en
|
||||
renseignant l'IP de votre machine et en ajoutant éventuellement des règles de
|
||||
pare-feu (mais cette dernière partie n'est pas demandée, gardez simplement en
|
||||
tête que cela doit pouvoir être fait manuellement au cas par cas : sur une
|
||||
machine sans pare-feu configurée, cela ne demande pas d'étape supplémentaire).
|
||||
Le service doit être accessible sur votre réseau local, sur un port
|
||||
configurable.
|
||||
|
||||
Votre script devra se limiter aux notions vues durant cette partie du TP
|
||||
(ie. sans utiliser `docker-compose` ou `docker stack` que l'on verra dans la
|
||||
seconde partie). Il pourra cependant faire usage des commandes `docker OBJECT
|
||||
inspect` pour ne pas avoir à faire d'analyse syntaxique sur les retours des
|
||||
commandes lisibles par les humains.
|
||||
Votre playbook devrait se limiter au module
|
||||
[`docker-container`](https://docs.ansible.com/ansible/latest/modules/docker_container_module.html)
|
||||
(ie. sans utiliser `docker-compose` ou `docker stack` que l'on verra dans un
|
||||
second temps).
|
||||
|
||||
Cette instance devra utiliser une base de données MySQL (lancée par vos soins
|
||||
dans un autre conteneur) et contenir ses données dans un ou plusieurs volumes
|
||||
(afin qu'elles persistent à une mise à jour des conteneurs par exemple).
|
||||
Cette instance devra utiliser une base de données MySQL ou Postgres (lancée par
|
||||
vos soins dans un autre conteneur) et contenir ses données dans un ou plusieurs
|
||||
volumes (afin qu'elles persistent notamment à une mise à jour des conteneurs).
|
||||
|
||||
L'exécution doit être la plus sécurisée possible (pas de port MySQL exposé sur
|
||||
l'hôte par exemple, etc.) et la plus respectueuse des bonnes pratiques que l'on
|
||||
|
|
@ -36,11 +30,6 @@ a pu voir durant ce premier cours.
|
|||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
42sh$ ./mycloud-run.sh
|
||||
http://localhost:12345/
|
||||
42sh$ #docker kill db
|
||||
42sh$ ./mycloud-run.sh # le script relancera une base de données,
|
||||
# sans avoir perdu les données
|
||||
http://localhost:12345/
|
||||
42sh$ ansible-playbook -i hosts my_cloud.yml
|
||||
```
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -32,8 +32,8 @@ cela dépendra de votre avancée dans le projet) :
|
|||
<div lang="en-US">
|
||||
```
|
||||
login_x-TP1/
|
||||
login_x-TP1/mycloud-run.sh
|
||||
login_x-TP1/...
|
||||
login_x-TP1/my_cloud.yml
|
||||
login_x-TP1/roles/...
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
|
|||
|
|
@ -2,5 +2,5 @@
|
|||
title: Virtualisation légère -- Projet n^o^ 1
|
||||
author: Pierre-Olivier *nemunaire* Mercier
|
||||
institute: EPITA
|
||||
date: EPITA -- SRS 2020
|
||||
date: EPITA -- SRS 2021
|
||||
...
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ envoyé à une autre adresse et/ou non signé et/ou reçu après la correction n
|
|||
sera pas pris en compte.
|
||||
|
||||
Par ailleurs, n'oubliez pas de répondre à
|
||||
[l'évaluation du cours](https://www.epitaf.fr/moodle/mod/quiz/view.php?id=213).
|
||||
[l'évaluation du cours](https://virli.nemunai.re/quiz/3).
|
||||
|
||||
|
||||
Tarball
|
||||
|
|
|
|||
|
|
@ -3,22 +3,22 @@ title: Virtualisation légère -- TP n^o^ 1
|
|||
subtitle: Les bases de Docker
|
||||
author: Pierre-Olivier *nemunaire* [Mercier]{.smallcaps}
|
||||
institute: EPITA
|
||||
date: Mercredi 2 octobre 2019
|
||||
date: Mardi 15 septembre 2020
|
||||
abstract: |
|
||||
Durant ce premier TP, nous allons apprendre à utiliser Docker, puis
|
||||
nous apprendrons à déployer un groupe de conteneurs !
|
||||
|
||||
\vspace{1em}
|
||||
|
||||
Le TP se termine par un petit projet à rendre à <virli@nemunai.re>
|
||||
au plus tard le mercredi 16 octobre 2019 à 13 h 42, des questions de
|
||||
cours sont également à compléter avant cette date sur
|
||||
Epitaf. Consultez la dernière partie de ce TP pour les modalités.
|
||||
Le TP se termine par un petit projet à rendre à <virli@nemunai.re> au
|
||||
plus tard le **mardi 22 septembre 2020 à 12 h 42**. Consultez la
|
||||
dernière section de chaque partie pour plus d'information sur les
|
||||
éléments à rendre. Et n'oubliez pas de répondre aux [questions de
|
||||
cours](https://virli.nemunai.re/quiz/3).
|
||||
|
||||
En tant que personnes sensibilisées à la sécurité des échanges
|
||||
électroniques, vous devrez m'envoyer vos rendus signés avec votre
|
||||
clef PGP. Pensez à
|
||||
[me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re)
|
||||
faire signer votre clef et n'hésitez pas à [faire signer la
|
||||
En tant que personnes sensibilisées à la sécurité des échanges électroniques,
|
||||
vous devrez m'envoyer vos rendus signés avec votre clef PGP. Pensez à
|
||||
[me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re) faire signer
|
||||
votre clef et n'hésitez pas à [faire signer la
|
||||
votre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
...
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ contiendra les paramètres d'exécution.
|
|||
|
||||
<div lang="en-US">
|
||||
```yaml
|
||||
version: '3'
|
||||
version: "3.8"
|
||||
services:
|
||||
influxdb:
|
||||
...
|
||||
|
|
@ -35,7 +35,8 @@ Ce fichier est un condensé des options que nous passons habituellement au
|
|||
Notons toutefois la présence d'une ligne `version` ; il ne s'agit pas de la
|
||||
version de vos conteneurs, mais de la version du format de fichier
|
||||
`docker-compose` qui sera utilisé. Sans indication de version, la version
|
||||
originale sera utilisée.
|
||||
originale sera utilisée, ne vous permettant pas d'utiliser les dernières
|
||||
fonctionnalités de Docker.
|
||||
|
||||
|
||||
### `services`
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Le premier conteneur qui doit être lancé est la base de données orientée sé
|
|||
temporelles :
|
||||
[InfluxDB](https://www.influxdata.com/time-series-platform/influxdb/).
|
||||
En effet, tous les autres conteneurs ont besoin de cette base de données pour
|
||||
fonctionner correctement : il serait impossible à *Chronograf* d'afficher les
|
||||
fonctionner correctement\ : il serait impossible à *Chronograf* d'afficher les
|
||||
données sans base de données, tout comme *Telegraf* ne pourrait écrire les
|
||||
métriques dans une base de données à l'arrêt.
|
||||
|
||||
|
|
@ -48,8 +48,8 @@ le client fourni :
|
|||
```
|
||||
42sh$ docker container run --rm -it --link mytsdb:influxdb --entrypoint "/usr/bin/influx" \
|
||||
influxdb -host influxdb
|
||||
Connected to http://influxdb:8086 version 1.6.3
|
||||
InfluxDB shell version: 1.6.3
|
||||
Connected to http://influxdb:8086 version 1.8.2
|
||||
InfluxDB shell version: 1.8.2
|
||||
> show databases
|
||||
name: databases
|
||||
name
|
||||
|
|
@ -85,7 +85,7 @@ système. Pour cela, on commence par télécharger *Telegraf* :
|
|||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
curl https://dl.influxdata.com/telegraf/releases/telegraf-1.8.1-static_linux_amd64.tar.gz | \
|
||||
curl https://dl.influxdata.com/telegraf/releases/telegraf-1.15.3_linux_amd64.tar.gz | \
|
||||
tar xzv -C /tmp
|
||||
```
|
||||
</div>
|
||||
|
|
@ -95,7 +95,7 @@ Puis, lançons *Telegraf* :
|
|||
<div lang="en-US">
|
||||
```bash
|
||||
cd /tmp/telegraf
|
||||
./telegraf --config telegraf.conf
|
||||
./usr/bin/telegraf --config etc/telegraf/telegraf.conf
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -110,7 +110,7 @@ Et observons ensuite :
|
|||
```bash
|
||||
42sh$ docker container run --rm -it --link mytsdb:influxdb --entrypoint "/usr/bin/influx" \
|
||||
influxdb -host influxdb
|
||||
InfluxDB shell version: 1.6.3
|
||||
InfluxDB shell version: 1.8.2
|
||||
> show databases
|
||||
name: databases
|
||||
name
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ envoyé à une autre adresse et/ou non signé et/ou reçu après la correction n
|
|||
sera pas pris en compte.
|
||||
|
||||
Par ailleurs, n'oubliez pas de répondre à
|
||||
[l'évaluation du cours](https://www.epitaf.fr/moodle/mod/quiz/view.php?id=213).
|
||||
[l'évaluation du cours](https://virli.nemunai.re/quiz/3).
|
||||
|
||||
|
||||
Tarball
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ tous les scripts. Nous pouvons l'installer en suivant la procédure suivante :
|
|||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
curl -L https://github.com/docker/compose/releases/download/1.24.1/docker-compose-Linux-x86_64 \
|
||||
curl -L https://github.com/docker/compose/releases/download/1.27.2/docker-compose-Linux-x86_64 \
|
||||
> /usr/bin/docker-compose
|
||||
chmod +x /usr/bin/docker-compose
|
||||
```
|
||||
|
|
@ -54,7 +54,7 @@ Comme avec Docker, nous pouvons vérifier le bon fonctionnement de
|
|||
<div lang="en-US">
|
||||
```
|
||||
42sh$ docker-compose --version
|
||||
docker-compose version: 1.24.1
|
||||
docker-compose version: 1.27.2
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
|
|||
|
|
@ -137,10 +137,96 @@ l'installation d'un paquet) s'applique à d'autres conteneurs, il va falloir
|
|||
créer une nouvelle image à partir de ce conteneur.
|
||||
|
||||
|
||||
### Programme par défaut
|
||||
|
||||
Chaque image vient avec un certain nombre de métadonnées, notamment le
|
||||
programme à exécuter par défaut si l'on ne le précise pas dans la ligne de
|
||||
commande.
|
||||
|
||||
C'est grâce à cela que vous n'avez pas eu besoin de préciser de programme
|
||||
lorsque vous avez lancé l'image `hello-world` :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
docker container run hello-world
|
||||
```
|
||||
</div>
|
||||
|
||||
Il est commun que le programme le plus attendu/approprié soit lancé par défaut,
|
||||
il est donc tout naturel que pour l'image `hello-world`, ce soit `/hello` :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
docker container run hello-world /hello
|
||||
```
|
||||
</div>
|
||||
|
||||
L'image ne contenant que ce programme, vous ne pourrez pas y lancer de shell :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
42sh$ docker container run hello-world /bin/sh
|
||||
docker: Error response from daemon: OCI runtime create failed: container_linux.go:349:
|
||||
starting container process caused "exec: \"/bin/sh\": stat /bin/sh: no such file or directory": unknown.
|
||||
```
|
||||
</div>
|
||||
|
||||
Pour les images `alpine` et `ubuntu`, le programme par défaut est un shell
|
||||
(`/bin/ash` pour `alpine` et `/bin/bash` pour `ubuntu`), mais il y a une
|
||||
subtilité : il faut ajouter les options `--interactive` et `--tty` pour ne pas
|
||||
que `docker` nous rende la main tout de suite :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
42sh$ docker container run alpine
|
||||
42sh$ echo $?
|
||||
0
|
||||
```
|
||||
</div>
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
42sh$ docker container run --interactive --tty alpine
|
||||
/ # _
|
||||
```
|
||||
</div>
|
||||
|
||||
En fait, comme on a vu que le programme `docker` n'est qu'un client du daemon,
|
||||
c'est toujours le daemon qui exécute directement les commandes et gère les
|
||||
entrées et sorties standards et d'erreur. Avec l'option `--interactive`, on
|
||||
s'assure que l'entrée standard ne sera pas fermée (`close(2)`). Nous demandons
|
||||
également l'allocation d'un TTY, sans quoi `bash` ne se lancera pas en mode
|
||||
interractif[^bashnointer].
|
||||
|
||||
[^bashnointer]: Mais il sera possible de l'utiliser sans allouer de TTY, comme
|
||||
dans cet exemple :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ cat cmd
|
||||
echo foo
|
||||
42sh$ cat cmd | docker run -i busybox
|
||||
foo
|
||||
```
|
||||
</div>
|
||||
|
||||
L'option `-i` reste néanmoins nécessaire pour que l'entrée standard soit
|
||||
transmise au conteneur.
|
||||
|
||||
Rassurez-vous, on peut les abbréger en `-i` et `-t` :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
42sh$ docker container run -it alpine
|
||||
/ # _
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
### Les paramètres
|
||||
|
||||
Vous avez remarqué l'utilisation des options `--tty` et `--interactive` ? Avant
|
||||
le nom de l'image, elles sont gérées par Docker pour modifier le comportement
|
||||
Vous avez remarqué le placement des options `--tty` et `--interactive` ? Avant
|
||||
le nom de l'image, elles sont utilisées par Docker pour modifier le comportement
|
||||
du `run`. En fait, tout comme `git(1)` et ses sous-commandes, chaque niveau de
|
||||
commande peut prendre des paramètres :
|
||||
|
||||
|
|
@ -164,30 +250,11 @@ l'emplacement du point de communication avec le daemon), tandis que les options
|
|||
simplement transmis au conteneur comme argument au premier `execve(2)` du
|
||||
conteneur.
|
||||
|
||||
Avec l'option `--interactive`, on s'assure que l'entrée standard ne sera pas
|
||||
fermée (`close(2)`). Nous demandons également l'allocation d'un TTY,
|
||||
sans quoi `bash` ne se lancera pas en mode interractif[^bashnointer].
|
||||
|
||||
[^bashnointer]: Mais il sera possible de l'utiliser sans allouer de TTY, comme
|
||||
par exemple en faisant :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ cat cmd
|
||||
echo foo
|
||||
42sh$ cat cmd | docker run -i busybox
|
||||
foo
|
||||
```
|
||||
</div>
|
||||
|
||||
L'option `-i` reste néanmoins nécessaire pour que l'entrée standard soit
|
||||
transmise au conteneur.
|
||||
|
||||
|
||||
## Lister les conteneurs
|
||||
|
||||
Avant de quitter notre conteneur, regardons, à l'aide d'un autre terminal,
|
||||
l'état de notre conteneur. La commande suivnate permet d'obtenir la liste des
|
||||
l'état de notre conteneur. La commande suivante permet d'obtenir la liste des
|
||||
conteneurs en cours d'exécution :
|
||||
|
||||
<div lang="en-US">
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ Assurez-vous également d'avoir un noyau récent, avec la commande `uname -r` :
|
|||
|
||||
<div lang="en-US">
|
||||
```
|
||||
5.2.14-gentoo
|
||||
5.8.9-gentoo
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -44,7 +44,7 @@ version déjà bien éprouvée, pour ce cours, nous allons avoir besoin de la
|
|||
**dernière version disponible**. Référez-vous à la documentation officielle
|
||||
correspondant à votre distribution :
|
||||
|
||||
<https://docs.docker.com/install/linux/docker-ce/debian/>
|
||||
<https://docs.docker.com/engine/install/debian/>
|
||||
|
||||
**Et Kali Linux alors ?** Kali étant basée sur Debian, référez-vous à
|
||||
la procédure d'installation de cette distribution.
|
||||
|
|
@ -93,47 +93,36 @@ Une sortie similaire au bloc suivant devrait apparaître sur votre écran :
|
|||
<div lang="en-US">
|
||||
```
|
||||
Client:
|
||||
Version: 19.03.2
|
||||
Version: 19.03.12
|
||||
API version: 1.40
|
||||
Go version: go1.12.9
|
||||
Git commit: 6a30dfc
|
||||
Built: Mon Sep 16 15:56:27 2019
|
||||
Go version: go1.14.6
|
||||
Git commit: 48a66213fe
|
||||
Built: Thu Aug 6 01:27:59 2020
|
||||
OS/Arch: linux/amd64
|
||||
Experimental: false
|
||||
|
||||
Server:
|
||||
Engine:
|
||||
Version: 19.03.2
|
||||
Version: 19.03.12
|
||||
API version: 1.40 (minimum version 1.12)
|
||||
Go version: go1.12.9
|
||||
Git commit: 6a30dfc
|
||||
Built: Mon Sep 16 15:55:09 2019
|
||||
Go version: go1.14.6
|
||||
Git commit: 48a66213fe
|
||||
Built: Thu Aug 6 01:26:25 2020
|
||||
OS/Arch: linux/amd64
|
||||
Experimental: true
|
||||
containerd:
|
||||
Version: 1.2.13
|
||||
GitCommit: 35bd7a5f69c13e1563af8a93431411cd9ecf5021
|
||||
runc:
|
||||
Version: 1.0.0-rc10
|
||||
GitCommit:
|
||||
docker-init:
|
||||
Version: 0.18.0
|
||||
GitCommit: fec3683b971d9c3ef73f284f176672c44b448662
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
### Versions de Docker
|
||||
|
||||
Historiquement, Docker est un projet open-source. Depuis quelques années, le
|
||||
business-model de la société a évolué et ils proposent désormais deux
|
||||
éditions : *Community Edition* et *Enterprise Edition*. La seconde est payante
|
||||
et possède un certain nombre d'atouts pour faciliter son adoption en entreprise
|
||||
(notamment pas mal d'interfaces graphiques, etc.). Le cœur de la technologie,
|
||||
qui nous intéresse princialement dans ce cours, est entièrement présent dans
|
||||
l'édition communautaire, sans limitation.
|
||||
|
||||
Depuis mars 2017, les numéros de version de Docker sont tirés de l'année et
|
||||
du mois de parution (comme on a l'habitude avec Ubuntu 16.04 par exemple). Le
|
||||
rythme actuel de parution est d'une version par trimestre (mars, juin,
|
||||
septembre, décembre).[^versions]
|
||||
|
||||
[^versions]: Tous les détails sur les versions (CE/EE et numérotation,
|
||||
fréquences, ...) sont résumés dans cette annonce :
|
||||
<https://blog.docker.com/2017/03/docker-enterprise-edition/>
|
||||
|
||||
|
||||
### `no such file or directory`?
|
||||
|
||||
Si vous avez cette erreur : `dial unix /var/run/docker.sock: no such file or
|
||||
|
|
|
|||
|
|
@ -105,8 +105,8 @@ de données.
|
|||
|
||||
Ne vous embêtez pas avec les mots de passes des services, initialisez la base
|
||||
de données avec le nom d'utilisateur et le mot de passe par défaut. Vous les
|
||||
obtiendrez en lisant l'aide (et la [documentation de l'image
|
||||
MySQL](https://hub.docker.com/_/mysql/)) :
|
||||
obtiendrez en lisant l'aide et la [documentation de l'image
|
||||
MySQL](https://hub.docker.com/_/mysql/) :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
|
|||
|
|
@ -36,6 +36,11 @@ docker container run --rm -p 80:80 -v ~/Downloads:/usr/share/nginx/html:ro -d ng
|
|||
Une fois cette commande lancée, votre voisin pourra accéder à votre dossier
|
||||
Downloads en renseignant l'IP de votre machine dans son navigateur favori !
|
||||
|
||||
Par défaut, `nginx` ne va pas permettre de lister le contenu du répertoire (et
|
||||
va afficher une page 404, car il cherche un fichier `index.html` dans votre
|
||||
répertoire). Vous pouvez par contre accéder à un fichier directement, par
|
||||
exemple : <http://10.42.12.23/dQw4w9WgXcQ.mp4>
|
||||
|
||||
|
||||
## Les volumes
|
||||
|
||||
|
|
@ -58,7 +63,7 @@ Ensuite, nous pouvons démarrer un conteneur utilisant, par exemple :
|
|||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
docker container run --mount source=prod_youp0m,target=/srv/images nemunaire/youp0m
|
||||
docker container run --mount source=prod_youp0m,target=/images nemunaire/youp0m
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -85,7 +90,7 @@ exclusivement en RAM\ :
|
|||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
docker container run --mount type=tmpfs,target=/srv/images nemunaire/youp0m
|
||||
docker container run --mount type=tmpfs,target=/images nemunaire/youp0m
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -105,8 +110,8 @@ même volume :
|
|||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
docker container run -d --mount source=prod_youp0m,target=/srv/images -p 8080:8080 nemunaire/youp0m
|
||||
docker container run -d --mount source=prod_youp0m,target=/srv/images -p 8081:8080 nemunaire/youp0m
|
||||
docker container run -d --mount source=prod_youp0m,target=/images -p 8080:8080 nemunaire/youp0m
|
||||
docker container run -d --mount source=prod_youp0m,target=/images -p 8081:8080 nemunaire/youp0m
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue