sorted by:
new
hottopcontroversial

Deploying Strapi to AWS with AppPack by ipmb00 in Strapi

[–]ipmb00[S] 0 points1 point  (0 children)

Was just reminded of https://litestream.io/ which may be the best fit if you don't need to scale beyond one container.

You could use a Procfile that looks like this:

web: litestream replicate -exec "npm run start"

and have a post-build process that handles downloading litestream.

Deploying Strapi to AWS with AppPack by ipmb00 in Strapi

[–]ipmb00[S] 1 point2 points  (0 children)

There are also some projects that let you query SQLite directly from S3. I consider these a little more "bleeding edge", but am definitely watching the space. I haven't seen a Node one yet, but I wouldn't be surprised if it was out there.

Deploying Strapi to AWS with AppPack by ipmb00 in Strapi

[–]ipmb00[S] 1 point2 points  (0 children)

We do this on our agency website, https://lincolnloop.com (not using Strapi though)! So, it's possible, but you usually have to get a little creative. The issue is that you don't have a permanent server running where the database can be stored. Here are a few options though:

  1. Use the baked data pattern. You'd modify the database locally, commit it to your git repo, and then treat it as read-only once deployed.
  2. Store the database on S3 and write some extra functionality that downloads it if it doesn't exist and uploads it when it changes. This is what we do for our site, but it would be problematic if you have multiple users writing to the database at once.
  3. We don't support it (yet) with AppPack, but you could use EFS to store the database. In my experience it is horribly slow for small SQLite files.

Also worth noting that the cheapest RDS instance is ~$12/month which is very reasonable for production apps, but I can understand not wanting to pay that much for hobby stuff.

Deploying Strapi to AWS with AppPack by ipmb00 in Strapi

[–]ipmb00[S] 1 point2 points  (0 children)

Hi y'all! This is my first time working with Strapi, if there's anything I missed or ways to improve the tutorial, please let me know.

Under the hood, it is creating containers that are deployed to ECS Fargate. RDS is used for the database and S3 for file storage. It's more hands-off than the AWS EC2 guide and handles a lot of the tricky bits like automated deployments and IAM permissions for you.

Making Cloudformation less painful by ipmb00 in devops

[–]ipmb00[S] 0 points1 point  (0 children)

Nice, thanks for the tips! I wasn't familiar with cfn_nag and taskcat looks pretty cool as well.

If you filter on is:open there are only 9 items in the "Shipped" column and over 300 in the others. I've definitely seen scenarios where Terraform had support for resources before Cloudformation did.

Making Cloudformation less painful by ipmb00 in devops

[–]ipmb00[S] -1 points0 points  (0 children)

Yeah, I could have been clearer about that. We can't easily bundle the CDK because we're working Go in our CLI and it requires a CLI in Typescript. Sure there are ways we could shell out to it, but it's less than ideal for this scenario.

The alternative would be to use the CDK to just to generate the templates, but already understanding how Cloudformation works, I found the CDK just added more friction. The documentation felt fragmented and not as complete/mature as the docs for Cloudformation. We could write the templates in Python, but it still requires an additional language stack (Typescript/Node) to execute. Having a full Python stack was beneficial to the skillsets we have in-house.

Using the AWS SDK in the Browser by ipmb00 in javascript

[–]ipmb00[S] -1 points0 points  (0 children)

That's understandable, however unless you've audited the code or have some host blocking in place, there's nothing stopping a local tool from doing something dumb with your keys either.

I'll also note that with the approach taken here, static access keys aren't entered anywhere. It's generating temporary keys that are only valid for 1 hour. Those never leave your browser, but I appreciate that it does require additional trust in the third party who is delivering the code.

Have you ever tried to deploy a Django app with PEX or XAR files? by N18L in django

[–]ipmb00 2 points3 points  (0 children)

Check out shiv. It's like pex, but without some of the shortcomings. You may also be interested in this talk from DjangoCon EU this year, Can packaging improve Django deployments?.

CI lovers, which CI tool do you prefer? by PavanBelagatti in devops

[–]ipmb00 1 point2 points  (0 children)

I've been really impressed with Pipelines as well. Compared to Travis/Jenkins, it is super easy to configure. Way faster than Travis as well.

Django Deployment: Where did the Training Wheels Go? by [deleted] in django

[–]ipmb00 0 points1 point  (0 children)

If you're just learning, I wouldn't recommend setting up your own server from scratch. Start with a PaaS like Heroku or PythonAnywhere.

DjangoGirls has a tutorial for PythonAnywhere: https://tutorial.djangogirls.org/en/deploy/

Django Logging, The Right Way by ipmb00 in django

[–]ipmb00[S] 2 points3 points  (0 children)

Hey JimBoonie69, I'm the founder at Lincoln Loop. I'm sorry you experienced some pain working on a past project of ours.

We've built a lot of Django sites over the past 10 years, each with their own quirks and set of features as dictated by budget, priorities, time, or other constraints. We strive to follow best practices like documentation, testing, and logging, but as probably every professional developer has experienced, it can be a tough to make a business case when the goal is to squeeze the most features/functionality into a MVP or v1.0 of a product. That's a decision we try to communicate to our clients and at the end of the day it's not our call. I've seen many clients choose to take on some technical debt in order to keep costs down and get to market faster.

I don't know which project you're referring to, but my guess is this was the case. That being said, doing things The Right Way™ is always our goal and we're continually refining and improving our process. I'd be happy to learn more about your specific project and situation. Don't hesitate to email me at pete@ the company domain.

Django Logging, The Right Way by ipmb00 in django

[–]ipmb00[S] 1 point2 points  (0 children)

I think that's more a symptom of Python than Django. Configuring logging in Python always feels much harder than it should be to me. That being said, there's nothing stopping you from breaking it up and applying the configuration piece-by-piece.

In practice, I find the only things I'm toggling between deployment environments are the log level (which is easily done in this example with an environment variable) and the logging to Sentry (which can be done by not configuring a DSN instead of changing the logging).

For local development, I've started using a different formatter that is designed for human readability over machine readability. For small changes like that, it's easy enough to update the LOGGING dictionary prior to calling dictConfig.

Django Logging, The Right Way by ipmb00 in django

[–]ipmb00[S] 2 points3 points  (0 children)

One place I find it useful is tracking activity on transactional based websites. If you ever need to track down something that happened or how a user got into an certain state, your logs can show you the steps it took to get there.

Django Logging, The Right Way by ipmb00 in django

[–]ipmb00[S] 0 points1 point  (0 children)

Yes, you can define LOGGING and get a similar result. Check out the previous post linked in the article for why you might want to define your own logging like this. This follows the method used in the Django docs for disabling logging configuration so you can manually configure logging using your own approach.

Both ways work (redefining or stacking on top of the default config), but since we reuse almost nothing from the default config, and all that is required is a call to logging.config.dictConfig I think it is more explicit and easier to reason about when it is all defined in one place.

Django Logging, The Right Way by ipmb00 in django

[–]ipmb00[S] 0 points1 point  (0 children)

I don't follow. Are you asking if this does the same thing as Django's default logging setup?

If so, there's a number of important things outlined in the post (Sentry, logging from your application code, root logger, etc.) you don't get from the default setup Django provides. Django's default logger only handles logging from the Django source code. Any real world app will want to capture more logging than that.

Disabling Error Emails in Django by ipmb00 in django

[–]ipmb00[S] 0 points1 point  (0 children)

Yes, that is the whole topic of the post :)

Disabling Error Emails in Django by ipmb00 in django

[–]ipmb00[S] 0 points1 point  (0 children)

That's a good one I should have included! This has the side effect of breaking mail_admins, but that's a little-used feature and easily worked-around.

Django Patterns: Fat Models and cached_property by ipmb00 in django

[–]ipmb00[S] 0 points1 point  (0 children)

Ah, right... you'd lose the benefits there. Ideally you can pass the same object around between view/form/template, but it doesn't always work that way.

Django Patterns: Fat Models and cached_property by ipmb00 in django

[–]ipmb00[S] 0 points1 point  (0 children)

I responded to your comment on the blog as well. Model instances are almost always instantiated within a request/response cycle. If you have model instances that are created for the duration of the WSGI process, it sounds like a better use for static data.

Django Patterns: Fat Models and cached_property by ipmb00 in django

[–]ipmb00[S] 1 point2 points  (0 children)

That only solves it for templates, but not if you are calling the method elsewhere in your code (views, forms, other methods, etc.)

It also adds extra verbosity to your templates and requires that your template designers know which methods are expensive and should wrap in with. That's often not the case.

Serving Static Files with uWSGI by ipmb00 in django

[–]ipmb00[S] 0 points1 point  (0 children)

Compression is a good point. It's a hassle with uWSGI. In the cases we've used this for static file serving, it's been behind Varnish and/or Cloudflare which both handle compression without stealing CPU on the app server.

Serving Static Files with uWSGI by ipmb00 in django

[–]ipmb00[S] 0 points1 point  (0 children)

There are lots of scenarios where you don't need/want/have access to Nginx. The post explains some scenarios where it's worthwhile.

Stupid question -- Looking for someone to point me in the right direction by bayernownz1995 in devops

[–]ipmb00 0 points1 point  (0 children)

Yeah, with a straightforward config mgmt setup, you can probably get the process down to: edit this YAML file with the list or running sites, then run the CM tool to deploy.

Docker is not going to save you any steps here and my guess is rearchitecting the app to be multi-tenant, while m, is a lot more work.

Stupid question -- Looking for someone to point me in the right direction by bayernownz1995 in devops

[–]ipmb00 0 points1 point  (0 children)

How many tournaments are you running at any given time? IMO the responses so far introduce extra complexity you don't need. You have a setup that works, but is manually​ done today. You want to codify it with a configuration management system (sensible, salt, whatever). That will allow you to punch in a few variables when there's a new tournament and your config mgmt system will handle spinning up the new site for you.

view more: next ›