Ciao,
mi servirebbe un aiuto da neofita di docker e python.
Devo dockerizzare un'applicazione python, che su una vm funziona senza problemi lanciando lo script python (es. ./script.py start o python3 script.py start)
Se sul dockerfile non metto alcun CMD o ENTRYPOINT e lo lancio interattivamente, il comando lanciato manualmente funziona e lo script viene lanciato e lasciato in esecuzione a tempo indeterminato (lo script verifica alcuni stream live e quando vanno online li salva in locale).

Ora, per far partire lo script in automatico sul container ho provato
ENTRYPOINT ["python3", "script.py", "start"]
ENTRYPOINT ["./script.py", "start"]

ma il container parte e termina come se lo script fosse terminato quando invece dovrebbe rimanere in esecuzione fino ad uno stop.

Come devo lanciare uno script python del genere nel dockerfile? Ho cercato in giro ma non ne vengo a capo

Grazie

Prova ad usare CMD al posto di ENTRYPOINT.

    asdrubalini avevo già provato, ma purtroppo non cambia.

    Guardando tra i vari tab ho trovato questo output:
    Error: the task 'Docker: cbr:latest' neither specifies a command nor a dependsOn property. The task will be ignored. Its definition is:
    {
    "type": "shell",
    "id": "shell,docker run --rm -it cbr:latest,",
    "idRandomizer": 0.8584129238166422,
    "problemMatcher": [],
    "label": "Docker: cbr:latest"
    }
    Error: the task 'Docker: cbr:latest' neither specifies a command nor a dependsOn property. The task will be ignored. Its definition is:
    {
    "type": "shell",
    "id": "shell,docker run --rm -it cbr:latest,",
    "idRandomizer": 0.8584129238166422,
    "problemMatcher": [],
    "label": "Docker: cbr:latest"
    }

        asdrubalini eccolo:

        FROM alpine:latest

        RUN mkdir /opt/cbr && mkdir /opt/cbr/ext

        WORKDIR /opt/cbr

        RUN apk update && apk upgrade

        RUN apk add python3 ffmpeg git py3-pip tzdata

        RUN pip3 install youtube-dl requests

        COPY . .

        RUN chmod +x Script.py

        ENTRYPOINT ["python3", "Script.py", "start"]

        L'ultima riga l'ho provata in varie varianti

            Prova così:

            FROM alpine:latest
RUN mkdir /opt/cbr && mkdir /opt/cbr/ext
WORKDIR /opt/cbr
RUN apk update && apk upgrade
RUN apk add python3 ffmpeg git py3-pip tzdata
RUN pip3 install youtube-dl requests
COPY . .
RUN chmod +x Script.py         
ENTRYPOINT ["/bin/sh"]
CMD  ["-c", "python3 /opt/cbr/Script.py start"]

              • [cancellato]

              • Messaggio #7

              MaxBarbero RUN apk update && apk upgrade

              sidenote: regole di "buona salute" imporrebbero di non fare mai upgrade dei pacchetti del sistema durante la build di una nuova immagine, altrimenti non hai la garanzia che il sistema sotto sia stabile e soprattutto le build non sono replicabili, perché di volta in volta le versioni dei pacchetti nei repo cambiano.

                  evilways Stesso risultato sull'output.

                  [cancellato] si vero, ma a questo punto dovrei fissare anche la distro e non usare la latest.
                  Diciamo che l'ho scritto un po' di corsa giusto per fare dei test che mi stanno facendo sudare 😀.
                  Su vm alpine funziona alla perfezione, ma volevo ridurre il footprint di memoria utilizzata sul nas

                  EDIT: ho fatto anche la prova fermandomi a ENTRYPOINT ["/bin/sh"]
                  ed escludendo l'ultima riga.
                  Lanciandolo in modo interattivo, se entro nel container posso lanciare a mano python3 /opt/cbr/Script.py start e il processo è up facendo un ps -eaf

                  EDIT2: Se lancio CMD ["-c", "python3"] entra in pyton e non chiude il container, ma se lancio la stringa completa sopra CMD ["-c", "python3 /opt/cbr/Script.py start"] termina il container

                        MaxBarbero a questo punto dovresti farci vedere lo script in python per capire il problema.

                          Controlla che lo script python abbia tutte le librerie di cui ha bisogno, magari gli manca qualcosa è crasha.
                          In alternativa prova ad aggiungere lo shebang python allo script e modificare il comando in ./Script.py start

                            alessio00 ciao, che abbia tutte le librerie ritengo di si, perchè da linea di comando dentro al container parte e resta in esecuzione, non dà alcun errore.

                            shebang intendi #!/usr/bin/python3 in testa allo script?
                            Quello c'è, posso lanciarlo da riga di comando come dici tu semplicemente usando ./Script.py start e anche quello funziona senza problemi anche da dentro il container in modalità interattiva.

                                • [cancellato]

                                • Messaggio #13

                                MaxBarbero Guarda i log del container e capisci cosa è successo, altrimenti vai alla cieca.

                                $ docker logs <nome-container>

                                    [cancellato] Con qualche difficoltà sono riuscito a recuperare qualcosa. Nel senso che se lancio il container la prima volta e guardo i log, questi sono vuoti (il container fa exit 0, quindi per lui dovrebbe essere a posto).
                                    Se lo rilancio e guardo i log vedo:
                                    Pid file found, is Script already running? pid: 8

                                    Questo perchè quando lo script Python parte e scrive in un file il pid del processo, quindi deduco che lo script parte, ma il container pensa di aver finito e si chiude (exit 0). Il successivo riavvio, non avendo fatto uno stop dello script graceful, si trova il file con il pid e pensa sia in esecuzione.

                                    In questo ultimo caso l'ho laciato con
                                    ENTRYPOINT ["./Script.py", "start"]

                                    Immagino che devo capire perchè il container pernsa di dover terminare non vedendo il processo

                                        • [cancellato]

                                        • Messaggio #15

                                        MaxBarbero 'spetta, ma il tuo script fa un "fork" e passa in background? Perché in questo caso sì, il processo lanciato dall'entrypoint termina e docker distrugge tutto, perché per lui il lavoro è finito.
                                        Dovresti fare in modo che parta in modo interattivo senza sganciarsi, in modo da restare attivo.

                                            [cancellato] mi sa che hai centrato il problema. Putroppo non ho molte conoscenze di programmazione, ma guardando il codice di un altro script richiamato:

                                            `
                                            def daemonize(self):
                                            self.logger.info("Starting daemon")
                                            self.logger.debug("calling os.fork()")

                                                # double fork
    try:
        # Note: os.fork() "returns 0 in the child process and child’s process id in the parent process".
        # See https://www.geeksforgeeks.org/python-os-fork-method/
        pid = os.fork()
        if pid > 0:
            self.logger.debug("Parent PID = {}".format(os.getpid()))
            sys.exit(0)
        
        pid = os.fork()
        if pid > 0:
            self.logger.debug("Fork PID = {}".format(os.getpid()))
            sys.exit(0)
        
            self.logger.debug("Double Fork PID = {} - fully daemonized".format(os.getpid()))`

                                            A sto punto chiedo al maintainer dello script qualche modifica 😀

                                              Informativa privacy - Informativa cookie - Termini e condizioni - Regolamento - Disclaimer - 🏳️‍🌈
                                              P.I. IT16712091004 - info@fibraclick.it

                                              ♻️ Il server di questo sito è alimentato al 100% con energia rinnovabile