21–30 of 30 posts
I still prefer to use kubernetes for this: https://dewyatt.github.io/articles/continuous-deployment-of-...
Is it worth it for just one server? Also, how do you handle the database? Do you put that in a container too?
Yes, the database can be in a container as well, with a persistent volume.
It's not that much more complex than what you just went through.
Earlier quoted context omitted.
How do you prevent downtime from Docker restarting?
That is an excellent question! I don't, right now, but I'll find a way!
I'm in a very similar situation as what you've got described, and I'll start in on that part of the project sometime in the next month or so.
Also been looking at Elastic Beanstalk for deployments. Have you looked at that yet?
# Remove the git repo to save space.
RUN rm -rf /code/.git
Pretty sure that it will not save any space because it will be in separate layer. If you want space to be saved to should be done as "one command".
RUN git clone ... /code/ && rm -rf /code/.git
Nice article but there is a fundamental thing missing: how to deploy and manage the fleet of containers to avoid downtime (e.g. having a systemd service that stops the container(s) and starts them with the new image is not optimal) and centralize logging. From my experience "deploying" containers is pretty easy: build the image, push the image, pull the image, start container. The hard parts are: how to deal with per…
Nice article but there is a fundamental thing missing: how to deploy and manage the fleet of containers to avoid downtime (e.g. having a systemd service that stops the container(s) and starts them with the new image is not optimal) and centralize logging. From my experience "deploying" containers is pretty easy: build the image, push the image, pull the image, start container. The hard parts are: how to deal with per…
Earlier quoted context omitted.
That is an excellent question! I don't, right now, but I'll find a way!
I think the "right" answer here is to put something like nginx in front with load balancing, and rolling restarts, or something like that. I'm in a very similar situation as what you've got described, and I'll start in on that part of the project sometime in the next month or so. Also been looking at Elastic Beanstalk for deployments. Have you looked at that yet?
I don't know how you'd communicate with nginx inside the container to tell it to switch, though, or how you would be able to know when all requests were done on the old container. Hopefully there's an easy way.
Too bad that a single SIGHUP becomes so complicated with containers, but I guess it's a tradeoff.
About the Beanstalk, I haven't looked into it too much, maybe that can help with deployment. I'd be grateful if you could let me know how it worked, if you ever try it out.
Earlier quoted context omitted.
Is it worth it for just one server? Also, how do you handle the database? Do you put that in a container too?
For production, it may be. Kubernetes would handle updates in a safer way, avoiding service interruptions. Yes, the database can be in a container as well, with a persistent volume. It's not that much more complex than what you just went through.
In Dockerfile: # Remove the git repo to save space. RUN rm -rf /code/.git Pretty sure that it will not save any space because it will be in separate layer. If you want space to be saved to should be done as "one command". RUN git clone ... /code/ && rm -rf /code/.git
Earlier quoted context omitted.
For production, it may be. Kubernetes would handle updates in a safer way, avoiding service interruptions. Yes, the database can be in a container as well, with a persistent volume. It's not that much more complex than what you just went through.
Ah, that sounds good. How does Kubernetes handle updates safely? That requires pretty deep integration with the thing running in the container, doesn't it?
It supports rolling updates where one pod (this means container, usually) is updated at a time, with traffic being sent to other pods during that time.
I think the best practice right now is to use a Deployment (alternatively you can initiate a rolling update manually). Using a deployment makes updates as simple as "kubectl patch ...".
It does require a load balancer, which varies from platform to platform. In AWS, I assume it uses an ELB. On premise, you might use contrib/service-loadbalancer (haproxy).
Earlier quoted context omitted.
Ah, that sounds good. How does Kubernetes handle updates safely? That requires pretty deep integration with the thing running in the container, doesn't it?
> How does Kubernetes handle updates safely? It supports rolling updates where one pod (this means container, usually) is updated at a time, with traffic being sent to other pods during that time. I think the best practice right now is to use a Deployment (alternatively you can initiate a rolling update manually). Using a deployment makes updates as simple as "kubectl patch ...". It does require a load balancer, whic…