• 3 Posts
  • 98 Comments
Joined 1 year ago
cake
Cake day: June 4th, 2023

help-circle
  • fubarx@lemmy.mltoPython@programming.devDeveloping with Docker
    link
    fedilink
    arrow-up
    2
    arrow-down
    1
    ·
    5 days ago

    OK, you wanted a conversation… :-)

    I did read the post, but I assumed it was the starting point of a system or mechanism, not the end-point. Wanting to just run “docker compose up” is fine, but there is more to developing and deploying to production (and continuing post-launch).

    That’s why I mentioned the CLI. It lets you go from a simple local app (Django on sqlite) to a Docker one (postgres, celery, redis, etc.), to all the way out to the cloud (ECS/EKS/serverless lambda/RDS), without having to remember what commands do what or managing lots of separate docker-compose files.

    I can see we are VERY far apart on how docker should be used in moving toward a production-ready system.

    For one thing, recommending putting secrets inside docker-compose is an instantly disqualifying piece of advice. There’s a whole ‘secrets’ section of docker compose that is there to prevent people from inadvertently including those in cleartext and baking them into images: https://docs.docker.com/compose/how-tos/use-secrets/.

    Github itself has a secret scanning mechanism to prevent leakage: https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning. For gitlab, there’s also Blackbox or HashiCorp vault. Putting AWS key/secret inside a repo can be VERY expensive and open one to legal liability if the account is misused. Repeated infractions could lead to AWS banning one’s account.

    I really recommend you take down that part of your post, instead of proliferating bad practices.

    As for the rest, to each their own.


  • fubarx@lemmy.mltoPython@programming.devDeveloping with Docker
    link
    fedilink
    arrow-up
    5
    arrow-down
    1
    ·
    5 days ago

    Good stuff.

    A few things I’d change:

    • A CLI to simplify local vs docker vs cloud operations. Reduces chance of operator error. Have had good luck with python click library.
    • Moving config settings into separate JSON and .env files to avoid loading too many config and secrets in the docker-compose file.
    • For AWS, I’d go with CDK. That way, cloud deployment is all in python (or typescript).
    • For cloud, you can also package Django into a single lambda, with dependencies inside a lambda layer. Not sure I’d use it in heavy production, but for small apps, really handy.
    • Inside Django settings, you can switch DB and services whether running local (sqlite, Redis), docker (postgres, RabbitMQ), or cloud (RDS, SQS).




  • I can think of only two reasons to have a venv inside a container:

    • If you’re running third-party services inside a container, pinned to different Python versions.

    • If you do local development without docker and scripts that have to activate the venv from inside the script. If you move the scripts inside the container, now you don’t have a venv. But then it’s easy to just check an environment variable and skip, if inside Docker.

    For most applications, it seems like an unnecessary extra step.


  • A few jobs ago, everyone hated the tech stack. The people who had come up with it had long left. I talked to everyone, then came up with a plan to transition to a modern stack. Got buy-in from management.

    Half the people (and all who had said they hated the status quo) threatened to quit if we made the change.

    Fortunately, it was just in time to collect the 1-year retention bonus. Life’s too short. Walked away.



  • Installed RabbitMQ for use in Python Celery (for task queue and crontab). Was pleasantly surprised it also offered MQTT support.

    Was originally planning on using a third-party, commercial combo websocket/push notification service. But between RabbitMQ/MQTT with websockets and Firebase Cloud Messaging, I’m getting all of it: queuing, MQTT pubsub, and cross-platform push, all for free. 🎉

    It all runs nicely in Docker and when time to deploy and scale, trust RabbitMQ more since it has solid cluster support.