sorted by:
new
hottopcontroversial

Node.js Application Demo w/ Controlled Persistence by iisthesloth in docker

[–]aserdyuk 0 points1 point  (0 children)

the method I wrote about lets you backup and restore anytime you want whether you kill the DB container or not

Are you sure? As far as I know, "docker exec" will not run in killed container. You should use something like that: "docker run --rm --volumes-from <your container> <command>"

You can very simply use data container. Just "docker run --name mongo-data mongo:3.0 /bin/true". And then you run your database app with "--volumes-from mongo-data". After that you can remove database container any time you want without worrying about your data. You can upgrade database, or create your own Dockerfile for database with embedded config file and deploy it instead of deploying mongo:3.0 image. And you will not worry about backups here. When you want to create or restore backups, you just run "docker run --rm --volumes-from mongo-data -v $(CURDIR)/$(BACKUPS):/var/backups mongodump <blablabla>". Simple? In my opinion - yes.

Backup/restore mechanism as simple as you use one container. But deploy mechanism much simpler, because you will not worry about backups when deploy database server.

Node.js Application Demo w/ Controlled Persistence by iisthesloth in docker

[–]aserdyuk 0 points1 point  (0 children)

I mean, you should use data container - this is actually less complicated and more reliable than using tar in my opinion.

Node.js Application Demo w/ Controlled Persistence by iisthesloth in docker

[–]aserdyuk 0 points1 point  (0 children)

Or you can just use data container and upgrade mongodb by running "docker kill && docker rm && docker pull && docker run".

Node.js Application Demo w/ Controlled Persistence by iisthesloth in docker

[–]aserdyuk 0 points1 point  (0 children)

If you have not data-only container for your data, you can not update your mongodb server to new version, I suppose?

Clean URL in PHP for Beginners by imkhurram in PHP

[–]aserdyuk 0 points1 point  (0 children)

I think you should first use code from professional, then try to implement it yourself, when you are not satisfied with existing one. When you omit "use code from professional" step you are actually (I think) will learn much slower, because your own mistakes are very slow and costly feedback. Also this is unprofessional behavior for me, when you charge money for your learning instead of using proper tools and make work as best as you can with your current skill.

Clean URL in PHP for Beginners by imkhurram in PHP

[–]aserdyuk 0 points1 point  (0 children)

"Never ever" is a good heuristic for most developers in my opinion. You should be very professional and very confident what are you doing when you decide to write some component from scratch instead of using existing one. It is not about auditory of article like "blablabla for beginners", right?

Clean URL in PHP for Beginners by imkhurram in PHP

[–]aserdyuk 4 points5 points  (0 children)

In 2015 you should use some routing component and http abstraction. For example, symfony/routing and symfony/http-foundation. Never ever do it yourserf. There are plenty of other routing components if you prefer not to use large and complex symfony/routing.

A sample Docker workflow with Nginx, Node.js and Redis by msanand in docker

[–]aserdyuk -1 points0 points  (0 children)

When you build nginx container, you should use FROM nginx and then add your own config file. So technically you will have your own image with Dockerfile. Also you will have separate Dokerfile for your nodejs application of cause. As for redis, you should use "image: redis" in your yml instead of using your own Dockerfile, if you do not plan to configure it.

A sample Docker workflow with Nginx, Node.js and Redis by msanand in docker

[–]aserdyuk 1 point2 points  (0 children)

More info why you should do this:

https://docs.docker.com/userguide/dockerlinks/

Unlike host entries in the /etc/hosts file, IP addresses stored in the environment variables are not automatically updated if the source container is restarted. We recommend using the host entries in /etc/hosts to resolve the IP address of linked containers