Bot Telegram + Python + Gestión recetas/menú semanal WIP

si te hace te lo dockerizo e inicializo postgresql en docker así será más sencillo ir tirando.

estaría bien tener menus guardados con comidas/cenas ( en lugar de recetas) yo por ejemplo no ceno lo mismo que como.

#6 jajajaj ok, lo tengo hecho para muchos lenguajes diferentes, para Python no me costará mucho, mi problema es de time management jajaj, que con la niña y toda la historia voy de culo

#8 Te lo he hecho al final, no me ha costado mucho aunque he tenido que cambiar la config y meterla en environment vars, no entiendo mucho de python aún y entiendo que hay formas mejor de hacerlo pero bueno:
https://github.com/Dynam1co/Python_Telegram_Bot/pull/3

He probado y funciona bien:

docker-compose build
docker-compose up (crea la base de datos on un init.sql de postgres docker, pero vamos que lo puedes cambiar a como te venga mejor)

Te recomiendo que programes en ingles, hay una mezcla muy rara de spanglish.

#1 Hace poco hice un proyecto con Dialogflow con NodeJS y NoSQL(Firebase) y desplegado en Telegram, y si quieres darle ese toque de conversación más natural con la ayuda de IA, échale un vistazo a DialogFlow, tiene mucho potencial. Y también en vez de botones (para que no ocupen en la pantalla) puedes probar los Suggestion o QuickReplies (aunque este componente lo vi en la librería de Dialogflow fulfilment, pero entiendo que Telegram debería tenerlo también)
que es para que le aparezca encima del teclado directamente

#12 La verdad es que yo debugeo muy poco y nunca lo he necesitado en docker, pero si hay tools que te meten otro compose override y tal, nunca lo he probado.

El auth de postgres me iba bien, lo tienes todo por environment vars. Me sacaba las recetas que tenía ya metidas (meti algunas a mano)

El de AEMET no llegue a probarlo, no tenía ni idea de cómo sacar el CityID.

¿Pero imagino que lo de AEMET es otro bot no?

#14 Postgres se crea directamente con user/password y base de datos en docker-compose. Si haces

docker-compose up

te crea todo. Y le paso por env-vars el user/pw/database name correctos. El bot se conecta bien vaya a la base de datos si lo haces por docker-compose.

El init.sql se pone en una carpeta determinada de la imagen de postgres, y lo pilla solo (puedes leerlo en los logs) la primera vez que lo inicias (puedes borrar todo con

docker-compose down -v

Probe ayer lo de AEMET, y no hace nada, probe con "id50297" ( http://www.aemet.es/en/eltiempo/prediccion/municipios/zaragoza-id50297 ) igual debería ser 50297. Ayer lo hice desde postman para obtener la lista de municipios.

Si tienes postgres corriendo en local, igual te falla al iniciar el postgres de docker-compose al pillar el mismo puerto en ambos sitios y estar ya pillado, y te falla por eso. Yo nunca me instalo nada en local si puedo evitarlo, me lo pongo siempre por docker, mysql, postgres, rabbitmq, redis, lo que haga falta, asi no se llena de mierda el portatil.

Fijate en el docker compose: (Te añado comentarios a las lineas importantes)

postgres:
    restart: unless-stopped
    image: "postgres"
    environment: 
      - POSTGRES_USER=recipesbot    #Este es el usuario root de postgres
      - POSTGRES_PASSWORD=recipesbot #Esta es la contraseña del usuario root
      - POSTGRES_DB=recipesbot  #Esta es la base de datos que se crea por defecto
    ports:
      - 5432:5432
    volumes:
      - database-data:/var/lib/postgresql/data/  # Aqui se guardan los datos de postgres
      - ./docker/postgres:/docker-entrypoint-initdb.d/  # Aqui va el init.sql que se ejecuta al crear la bd 
  recipesbot:
    restart: unless-stopped
    depends_on: 
      - postgres
    build: 
        context: .
    image: recipesbot
    environment: 
        - TELEGRAM_TOKEN=AAAA
        - TELEGRAM_GROUP_ID=1111
        - POSTGRES_HOST=postgres
        - POSTGRES_USER=recipesbot
        - POSTGRES_PASSWORD=recipesbot
        - POSTGRES_DATABASE=recipesbot
        - WEATHER_SCHEDULE=08:00,12:00,15:00,18:00,22:00,00:00

Te tienes que crear docker-compose.override.yml en local, y ponerle el environment que quieras, o un env-file si lo prefieres

#16 si ya le pasas el token, ya estás pasandolo por environment vars. Mira a ver si puedes conectarte al postgres del compose a ver si es que por lo que sea no se levanta bien.

#20 Con docker tengo asignatura pendiente...
Y veo que va muy de la mano con lo que haya en docker-hub en general. Ya que veo que al principio, mucho Dockerfile define las imagenes, y actualmente muchas se pueden llamar directamente de docker-hub (como la de postgres) con su parametrización citada en los readme.

Porque no llamas a la imagen directa de Python en el compose? Para poder usar el requirements en el Dockerfile y indicar el ejecutable directo una vez haga el "up"?

Tengo que apretar en DevOps... demasiados años de infra clasica :\
Quiero meterme con todo el mundo kubernetes, docker, ansible/terraform/cloudformation, pipelines, Jenkins, en fin...

#21 la idea es poder desplegar la imagen sin tener el código en el host. Asi luego es trivial ponerlo en K8s por ejemplo. Y si la imagen ya tiene el install hecho será más rápido de desplegar.

Se puede hacer como dices pero estarías duplicando el código que hay en el dockerfile en el compose, y dejarías de probar el del dockerfile.

Es la primera vez que lo hago para un lenguaje interpretado de todas formas.. por ll general se hace así porque hace falta compilarlo.

#24 creas un dockerfile con el codigo de un repo git o de cualquier lado y con compose cada vwz haces el build y el up y compilas o haces lo que tengas que hacer. Pero eso lo veo yo para CI despliegues y tal.

Para desarrollar es más comodo usar volúmenes imho.