no need other lib. only django-rest can handle.

I agree with

There's plenty of guides / tuto / books on how to develop with django but very litle on how to setup a dev/prod evviroment where you can push code and update existing running services. I want to set up an environment where we can deploy changes and or / run a developer versioni all on the same DB, what are the reccomendations around this. to have 2 dockerfiles, one for production and one for development is easy enough but wht/how do you update / develop on an existin gproduct?

There's plenty of guides / tuto / books on how to develop with django but very litle on how to setup a dev/prod evviroment where you can push code and update existing running services. I want to set up an environment where we can deploy changes and or / run a developer versioni all on the same DB, what are the reccomendations around this. to have 2 dockerfiles, one for production and one for development is easy enough but wht/how do you update / develop on an existin gproduct?

use heroku

There's plenty of guides / tuto / books on how to develop with django but very litle on how to setup a dev/prod evviroment where you can push code and update existing running services. I want to set up an environment where we can deploy changes and or / run a developer versioni all on the same DB, what are the reccomendations around this. to have 2 dockerfiles, one for production and one for development is easy enough but wht/how do you update / develop on an existin gproduct?

+1

use heroku

Our code/db will never leave the house so thats not an option.

There's plenty of guides / tuto / books on how to develop with django but very litle on how to setup a dev/prod evviroment where you can push code and update existing running services. I want to set up an environment where we can deploy changes and or / run a developer versioni all on the same DB, what are the reccomendations around this. to have 2 dockerfiles, one for production and one for development is easy enough but wht/how do you update / develop on an existin gproduct?

a good boilerplate with some examples: -> https://github.com/pydanny/cookiecutter-django

I don’t think it’s a good idea to have same database for both versions, that said i’m no where near publishing a scalable web app, but here are my 2 cents 💰 I usually run 2 different servers on same vps one for production usually nginx and another for development usually apache2 servers are not hard to setup just some configuration stuff, that is to have the same domain work on both serves just different ports they are pretty easy to configure and in case of ssh better to change the port and use rsa instead of password.

I was thinking more in line of docker, Ill wrap the environments in docker then I dont need the "same" db as I can spin up another instance of it making it "the same" but not. But the automatic push —> deploy solution is the ones I miss more totu / information around.

More like what happens if I generate new fields and models on the dev side, how do i migrate these changes to an active running app? Do I have to do it again in the excact same order ?

I could add the migrate commands to the docker-build fiile so this happens every time the image rebuilds, but again. Whats the common practice / "right" way to do things.

i haven’t use docker, i’m sure u’re smart enough to figure it out and keep us posted on what you’ve decided on doing

Sure 👍, if you are unfamilliar with docker i urge you to learn it! It won't take you long and is VERY usefull in many situations.

It’s on my to learn list, just need time

It’s on my to learn list, just need time

I know the feeling ;)

How do I add extra paths from this base_dir? BASE_DIR = Path(file ).Resolves ().Parent.parent.parent I've copied this code but I do not know very well how it works, for staic I used BASE_DIR / 'static', but I want to add other extra directories, I tried BASE_DIR / 'dir1' / 'dir2' and BASE_DIR / 'dir1/dir2' but I think that did not work

I was thinking more in line of docker, Ill wrap the environments in docker then I dont need the "same" db as I can spin up another instance of it making it "the same" but not. But the automatic push —> deploy solution is the ones I miss more totu / information around.

One idea could be to set a git hook so everytime you push your stable branch, it rebuilds everything with new code Or use some CI/CD platform so you always have tested code and build it only if it passes all of your tests But I still don't have so much experience I strongly believe suggests from @JimmySan are like gold 💪😎

Who's that?

and how do I configure django to use the static root directory locally? I only get static dirs and using --insecure, but that way I have to restart the server every time I make some changes

One idea could be to set a git hook so everytime you push your stable branch, it rebuilds everything with new code Or use some CI/CD platform so you always have tested code and build it only if it passes all of your tests But I still don't have so much experience I strongly believe suggests from @JimmySan are like gold 💪😎

its really a long topic. best practice comes with time. it depends from the kind of app and the workflow

i not use docker on production btw. only on dev stage

then with a ci/cd pipeline i deploy all update in different stage before production

to avoid disruptive update

then with a ci/cd pipeline i deploy all update in different stage before production

what a long road separating me from becoming pro 🤷‍♂️

what a long road separating me from becoming pro 🤷‍♂️

DTAP . d on docker. TAP on live stage. TA automatic. P manual

😊

If I well remember, some of old collegues used to write automatically deploy using Ansible and Makefile to speed up process so make dev, make beta and make prod etc.

yep. or fabric

or terraform

it depends from infra

Teach us senpai

please stop ✋

overwhelmed bar has reached its maximum

it depends from infra

Sure!

Is it sensible to use vagrant and virtual box to deploy our server?

I would say no

I would not run Virtual Box in production.

unless you mean "a" virtual box...

its really a long topic. best practice comes with time. it depends from the kind of app and the workflow

Thanks for the advice.

My job upuntil a year ago was a typical multisystem admin, så the admin part is not the problem. Its the CI/CD platform I need to learn. But like you said it depends on the project, and this project will always have the possibility of downtime for upgrades etc without a problem. At least for the unforseeable future.... So docker in production is a real option....

My job upuntil a year ago was a typical multisystem admin, så the admin part is not the problem. Its the CI/CD platform I need to learn. But like you said it depends on the project, and this project will always have the possibility of downtime for upgrades etc without a problem. At least for the unforseeable future.... So docker in production is a real option....

Now I'm finally playing with docker to learn it as better as I can

I run almost every service in docker. Either with Docker-compose or Docker-machine.

You have other tools like portainer that can help to but I like to keep it in the CLI

Me too 😀

😁

I run almost every service in docker. Either with Docker-compose or Docker-machine.

on production????

Yes.

have you stresstested your application with or without docker?

With, these are low traffic services, internal systems etx

Etc

aaah ok

'cause with docker i have bad performance

Like phpipam, intranet pages etc

with cri-o on kubernetes all good, docker with compose or not: a mess :(

'cause with docker i have bad performance

Then it can be your storage layer

What system do you run Docker on?

i don't think so... the databse is outside docker, clustered, and the files are saved on S3-compatible space

the service are api, i see a lot of issue on the network part too

You save files outside the container?

You save files outside the container?

obviously

the container are ephemeral: can die every moment

What kind of files?

like user uploads

pdf, img, blabla

Ah yes

inside the docker only the sourcecode

the container are ephemeral: can die every moment

What?

What?

evanescent

can die in every moment

it's not a virtualmachine

Not, thats why you should have access to the full resources of the machine and I think its very strange you have issues

I shares kernelspace with the local system... But whats your OS (you tried docker on in production)

centos

Well that sucks...

Its "no" secret Docker and CentOS have issues.

🤣🤣🤣

(doesnt suck for everything) hehe

are you serious?

very

😂🤣🤣🤣🤣🤣

Check out ubuntu and fedora, I would use Ubuntu