Salut à tous,
Les mecs j’ai un problème !
je souhaite installer mon instance Gladys sur mon openmediavault. J’ai un volume de disk dédié et je voulais faire l’installation dessus depuis un stack portainer et donc avec docker compose.
Je voulais juste changer la variable de volume:
/var/lib/gladysassistant:/var/lib/gladysassistant
par
/chemin de mon volume de disk/gladysassistant:/var/lib/gladysassistant
mais
lors de la configuration du service Zigbee2mqtt les conteneurs que crée Gladys se retrouve dans /var/lib/gladysassistant.
J’ai du coup essayé de changer les volumes de ces 2 conteneurs après leur création mais rien y fait.
Avez-vous une idée ?
(Pour le moment je tourne avec le volume /var/lib/gladysassistant et tout roule !)
Voilà je vous remercie !
VonOx
Novembre 9, 2022, 5:52
2
Hmm C’est pas normal ça, le code récupère le bind qui est configuré pour gladys.
/**
* @description Compute basePath in host and container from mounted point or give default ones.
* @returns {Promise} Base path in host/container to store files.
* @example
* const { basePathOnContainer, basePathOnHost } = await getGladysBasePath();
*/
async function getGladysBasePath() {
let basePathOnContainer = '/var/lib/gladysassistant';
// Fetch container path mount
if (process.env.SQLITE_FILE_PATH) {
const base = process.env.SQLITE_FILE_PATH;
basePathOnContainer = base.substring(0, base.lastIndexOf('/'));
}
// Find mount linked to this path to fetch host path
const currentContainerId = await this.getGladysContainerId();
const gladysMounts = await this.getContainerMounts(currentContainerId);
if (gladysMounts) {
const baseMount = gladysMounts.find((mount) => {
return mount.Destination === basePathOnContainer;
});
This file has been truncated. show original
Je vais tenter de reproduire. Tu est sur quelle architecture ?
Tu peux poster ton compose/stack ?
1 « J'aime »
Salut et toi et merci pour ton aide !
voila mon compose:
version: "3.3"
services:
gladys:
image: gladysassistant/gladys:v4
container_name: gladys
restart: always
network_mode: host
privileged: true
environment:
NODE_ENV: production
SQLITE_FILE_PATH: /var/lib/gladysassistant/gladys-production.db
SERVER_PORT: "5425"
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- /var/lib/gladysassistant:/var/lib/gladysassistant
#- ${ROOT}/gladysassistant:/var/lib/gladysassistant
- /dev:/dev
J’avais aussi utilisé ma variable ROOT pour le .db dans le SQLITE_FILE_PATH.
La variable ROOT est: ROOT= /srv/dev-disk-by-uuid-5338eaab-600f-4cba-ba84-cdee7b15fd65/appdata
Coté archi je suis sur un esxi qui héberge un OpenMediaVault sur lequel docker est installé.
J’avais un autre symptôme c’est que aucunes config n’étaient sauvegardées, je pense à un mélange entre les 2 dossiers.
Voila voila !
Pour moi c’est la variable d’environnement SQLITE_FILE_PATH
qui permet de définir quel chemin utiliser.
N’oublie pas que le conteneur tourne en privilégié sur l’OS, ce qui peut changer le comportement. Par exemple Gladys a accès à tout l’OS, contrairement à d’autres conteneurs.
@JulienB Je ne sais pas si c’est toi qui a créé l’issue Github et la PR, mais il y a effectivement un problème sur cette partie lorsque docker-compose est utilisé. Donc ça vient pas de ton côté, effectivement actuellement on ne support pas bien docker-compose
L’issue Github:
opened 06:28PM - 10 Nov 22 UTC
**Describe the bug**
When running Docker Gladys with docker compose every time … the container is restarted the MQTT configuration doesn't load (although is still saved in the database).
**To Reproduce**
Steps to reproduce the behavior:
1. With a docker compose file like this:
```yml
# docker-compose.yml
version: "3.3"
services:
gladys:
restart: always
privileged: true
network_mode: host
container_name: gladys
environment:
- NODE_ENV=production
- SERVER_PORT=8090
- TZ=Europe/Madrid
- SQLITE_FILE_PATH=/var/lib/gladysassistant/gladys-production.db
volumes:
- "/var/run/docker.sock:/var/run/docker.sock"
- "${LOCAL_DATA_DIR}/gladys:/var/lib/gladysassistant"
- "/dev:/dev"
- "/run/udev:/run/udev:ro"
image: "gladysassistant/gladys:v4"
mosquitto:
restart: always
container_name: mosquitto
image: eclipse-mosquitto:2
volumes:
- ${LOCAL_DATA_DIR}/mosquitto/config/:/mosquitto/config/
- ${LOCAL_DATA_DIR}/mosquitto/log/:/mosquitto/log/
- ${LOCAL_DATA_DIR}/mosquitto/data:/mosquitto/data/
ports:
- 1883:1883
- 9001:9001
```
3. Go to `<gladys-server-domain>/dashboard/integration/device/mqtt/setup`
4. Setup the Broker URL to `mqtt://localhost`
5. Everything should work fine
6. Restart the Gladys container
7. Go to `<gladys-server-domain>/dashboard/integration/device/mqtt/setup`
8. The Broker URL is lost
**Expected behavior**
It should keep loading the Broker URL after restart.
**Your Gladys installation (please complete the following information):**
- Raspberry Pi 4
- Debian GNU/Linux 11 (bullseye)
- Docker version 20.10.20, build 9fdeb9c
**Additional context**
When restarting the Docker container this logs are shown:
```
<warn> service.start.js:44 (Service.start) Unable to start service zigbee2mqtt PlatformNotCompatible [Error]: DOCKER_CGROUP_CONTAINER_ID_NOT_AVAILABLE
at System.getGladysContainerId (/src/server/lib/system/system.getGladysContainerId.js:45:13)
at System.getNetworkMode (/src/server/lib/system/system.getNetworkMode.js:16:25)
at Zigbee2mqttManager.init (/src/server/services/zigbee2mqtt/lib/init.js:18:23)
at Object.start (/src/server/services/zigbee2mqtt/index.js:17:5)
at Service.start (/src/server/lib/service/service.start.js:33:7)
```
After some research I found [this Stackoverflow entry](https://stackoverflow.com/questions/68816329/how-to-get-docker-container-id-from-within-the-container-with-cgroup-v2) which lead me to verify that `/proc/self/cgroup` is actually empty.
The issue can be solved when running docker using the `--cid` or `--cgroupns` flag, but none of those options is available in docker compose.
La PR qui corrige le bug:
GladysAssistant:master
← magarcia:fix/get-container-id
opened 07:15PM - 10 Nov 22 UTC
### Pull Request check-list
To ensure your Pull Request can be accepted as fa… st as possible, make sure to review and check all of these items:
- [x] If your changes affects code, did your write the tests?
- [x] Are tests passing? (`npm test` on both front/server)
- [x] Is the linter passing? (`npm run eslint` on both front/server)
- [x] Did you run prettier? (`npm run prettier` on both front/server)
- [ ] If you are adding a new features/services, did you run integration comparator? (`npm run compare-translations` on front)
- [ ] Did you test this pull request in real life? With real devices? If this development is a big feature or a new service, we recommend that you provide a Docker image to [the community](https://community.gladysassistant.com/) for testing before merging.
- [ ] If your changes modify the API (REST or Node.js), did you modify the API documentation? (Documentation is based on comments in code)
- [ ] If you are adding a new features/services which needs explanation, did you modify the user documentation? See [the GitHub repo](https://github.com/GladysAssistant/v4-website) and the [website](https://gladysassistant.com).
- [ ] Did you add fake requests data for the demo mode (`front/src/config/demo.js`) so that the demo website is working without a backend? (if needed) See [https://demo.gladysassistant.com](https://demo.gladysassistant.com).
NOTE: these things are not required to open a PR and can be done afterwards / while the PR is open.
### Description of change
This PR fixes #1647, when `/proc/self/cgroup` doesn't contain the container ID it tries to get it from `/proc/self/mountinfo`.
@VonOx Preneur de ton avis sur la PR
pierre-gilles:
Je ne sais pas si c’est toi qui a créé l’issue Github et la PR, mais il y a effectivement un problème sur cette partie lorsque docker-compose est utilisé. Donc ça vient pas de ton côté, effectivement actuellement on ne support pas bien docker-compose
A non ce n’est pas moi ! Mais je vais regarder ça ! Merci.
j’ai commencé a bossé avec la config par default. Je ferai des tests si il y a solution avant de revenir sur mon volume.
HAHA j’avais pas vu l’issue créé il y a 22h ! Ça aurait pu être moi effectivement !
VonOx
Novembre 11, 2022, 6:26
9
C’est très probablement lié
@JulienB le fix est live dans Gladys Assistant v4.12.2
Salut à tous,
Je viens de publier v4.12.2, une petite mise à jour qui corrige un bug pour les utilisateurs de docker-compose, désormais l’ID du container est correctement récupéré ce qui permet d’utiliser avec docker-compose les intégrations qui lancent des containers comme l’intégration Zigbee2mqtt par exemple !
Ce fix est la première contribution (#1648 ) d’un utilisateur espagnol, qu’on remercie pour sa première contribution
Le CHANGELOG complet est disponible ici .
Comment mettre à…
1 « J'aime »