61–70 of 116 posts
I deploy on bare metal. Docker, Kubernetes, et. al add layers of complexity that I don't need. I'm not saying that they don't have benefits at a certain scale, but for the types of single-server deployments I do, I have not been convinced.
I deploy on bare metal. Docker, Kubernetes, et. al add layers of complexity that I don't need. I'm not saying that they don't have benefits at a certain scale, but for the types of single-server deployments I do, I have not been convinced.
I recently(past 6 months) joined a new startup as the operations person, and we standardized on kubernetes for deployment. In the past I've worked with puppet/chef/ansible/heroku/aws/appengine/vmware you name it, and Kubernetes is the nicest and most flexible platform to build on top. There's a learning curve, and new features are being added, but at this point I would not hesitate to recommend Kubernetes to just abo…
Any thoughts on Concourse?
It is also very nice in that you can execute pipelines, and even just jobs, on the Concourse installation from your local CLI. This makes it much simpler to test pipeline/job tweaks without a single commit being necessary until it is verified to work. Yes, you can do something similar with the Jenkins Pipeline plugin suite using the Replay functionality but it is significantly more tedious (cut and paste from editor into a textbox in the Jenkins UI, bleh).
It's surprising the number of people who want to build a homebrew Kubes PaaS. When I first started working in development, every company was building its own CMS, until it invariably realised that it was hard and that they were better off using a commercial or open source solution. Seems that container-based platforms are history repeating itself.
To deploy code with Salt, we had an SSH account on the Salt server configured with a bunch of deploy keys. Each of those had a forced command that would read $SSH_ORIGINAL_COMMAND and forward this information to an agent (running as root) that would execute Salt with the correct arguments, based on information in $SSH_ORIGINAL_COMMAND. This let us use a build step in TeamCity that basically did ssh deploy@mgmt-gateway [env] [project] [version]. Deployments were logged to New Relic and Slack.
In a different team that are fond of PHP we use a private GitLab CE for code management, GitLab CI Multi-runner as the build agent for CI/CD, Ansible for configuration management and code deploys to different environments running on AWS EC2. Like in the previous team, we have configured our .gitlab-ci.yml to pass some arguments in $SSH_ORIGINAL_COMMAND over SSH to a management node that in turns talks to Ansible.
Something I like with having a private GitLab CE instance is that development doesn't stop because your public Git host is DDoSed or have other problems (like the recently discussed one here on HN).
Test and staging servers are shutdown/destroyed off-hours and restarted/recreated by cron jobs that execute Ansible plays which identify eligible EC2 instances via EC2 tags. Production environments with multiple servers are similarly scaled down during off-hours. By simply modifying/removing the "shutdown" tag from the AWS resources, teams are able to exclude their test/staging environments from the scheduled shutdowns, something which is useful for upcoming releases. ;)
In the Node/Golang shop I loved how simple Docker images were and how good it felt to deploy it to isolated containers. Unfortunately, I don't see how that's possible (in a clean way, preferrably without using two images) when both an Nginx process (static file serving, e.g. frontend resources) and a PHP-FPM process needs access to the same code release.
(If you have experience with Nginx/PHP-FPM apps and Docker, feel free to enlighten me!)
Things I'm not entirely fond of about GitLab CI is that:
- each branch in each repo must have a .gitlab-ci.yml that is up-to-date (administrative challenge!)
- it's entirely driven from a git push (though the web gui provides buttons for existing builds to retry/manually execute steps to e.g. deploy code)
GitLab has no support for a centrally managed .gitlab-ci.yml file on a project group and/or project level. There's no way to define variables on a project group and/or project level. There's no way to schedule jobs so that you can execute daily/weekly tests, or to manage jobs (in a user-friendly way via the web gui) that perform cron-like tasks, so you can avoid putting these tasks on the server themselves in /etc/cron.d (which becomes a problem when you restore backups / bake AMIs / do auto-scaling).
I'd love to look more into K8 and Google's cloud offerings, especially since I believe this might be the future and because I believe Google are lightyears ahead of the competition when it comes to security and protecting the privacy of its customers. Unfortunately I'm afraid it's not viable given my team's current investment in Nginx/PHP-FPM apps and various AWS services.
This is a great question and something we've been trying to figure out ourselves. Historically, we were using Ansible to deploy Docker containers to EC2 instances, but have moved some services over to Kubernetes, Swarm and Lambda/Serverless. All of these are create the same deployment challenges -- the current products out there don't fit perfectly. The more we want to deploy to a higher level than "just Docker", the…
It has a plugin model (CPIs) for hosting substrates, so right now it can deploy and upgrade systems on AWS, GCP, Azure, vSphere, OpenStack and there are others I forget right now.
It's proved itself in large production systems for years. Every week or two we entirely upgrade our public Cloud Foundry, PWS, and nobody ever notices.
OK, that's a lie. You get an email from CloudOps: "We're going to deploy v251". Then a few hours later: "v251 is deployed". Or occasionally: "Canaries failed, v251 was rolled back".
There's nice integration with Concourse[2,3]. You simply "put" your deployment and it just gets deployed for you. Our CloudOps team do this now, which makes their lives that much easier.
Versioning is trivial, especially if you're working in a commit-deploy model via Concourse.
The downside is that BOSH is BOSH.
We're doing lots of work to make it friendlier and more approachable, but right now it's powerful and very opinionated. It does not have a smooth onramp, because the basis of its power and reliability is that it insists on certain minimum conditions first.
It's really meant for operators, not developers, but at Pivotal the main consumers by volume are developers. Usually to deploy Cloud Foundry and Concourse; though my current assignment is actually going to be shipped purely as a BOSH release.
Disclosure: I work for Pivotal on Cloud Foundry.
[0] http://bosh.io/
[1] https://docs.cloudfoundry.org/deploying/common/deploy.html
I recently(past 6 months) joined a new startup as the operations person, and we standardized on kubernetes for deployment. In the past I've worked with puppet/chef/ansible/heroku/aws/appengine/vmware you name it, and Kubernetes is the nicest and most flexible platform to build on top. There's a learning curve, and new features are being added, but at this point I would not hesitate to recommend Kubernetes to just abo…
If you are doing a lot with docker images, it might be worth considering Concourse CI ( https://concourse.ci ). I haven't played with it in any depth yet so I'm not sure how it compares with other solutions, but I like the idea of your entire build pipeline running through docker images. Theoretically you should even be able to run it in kubernetes.
I use Convox ( http://www.convox.com ). It is backed by ECS which gets me out of the infrastructure game for the most part and the CLI interactions in Convox are similar to heroku style commands so the learning curve is much simpler than deploying and learning my own Kubernetes or OpenStack or ECS configurations. They've also thought of the other things you need like environment based secrets(uses DynamoDB and KMS be…
If you don't want to manage Kubernetes, you can use Google Container Engine (GKE), which is Kubernetes-as-a-service. A nice bonus is that they only charge you for the minion nodes. The Kube master is free.
Disclosure: I work for Pivotal on Cloud Foundry, a competing system.