mrsk 0.8.3 → 0.8.4

Sign up to get free protection for your applications and to get access to all the features.
checksums.yaml CHANGED
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  SHA256:
3
- metadata.gz: 0065b91bb3c00ef0ef6db78eb605d8db5df3606ccf97be15bb059ab1985231d5
4
- data.tar.gz: 2ed2b0c6235ea398bc5717aebf99e2a4f1e6c9434c64da5eed6d8899b0ca335e
3
+ metadata.gz: fccda4eb164533a6d31837fb7dbfc01eadb2ff51d6205d604a23c18c9acb594c
4
+ data.tar.gz: 94d1822f909dd32c3432d07fed8710b9476855b0bf47faf0bcca844058e0901e
5
5
  SHA512:
6
- metadata.gz: c00ed2e4693b62e0eeb238c17d4c17b3e06ed03ed580aea7ca724a4629c28274d77bc31fa63ca1d1e5f07b1f73e6b2ecc164a076d2ad5307b7e30625cea2ee7a
7
- data.tar.gz: ee273834e9e330640ef6b55acc4dabeeef6c4e9178112351376c3ab1e23afeb9fa389a08b6cf5a8c3bbaafc079d7cabc98d316fd08030a8886c12d5020a68653
6
+ metadata.gz: f4343eb5062fc6d3da82d6b10e35940a2574aa5913da3104398f5272f5e695fe6b9b97da5cc0d59635ea9c6b2d0758615d77d0974d6a69e086c96ebb3f21cb5b
7
+ data.tar.gz: 360e59e8d5646b67e45f4576c9bec3d771e38a5eae96e53ea3489bc3f51fe7607542b8c92f74b9d7a59257b85976444c3e8b648fa7858be2dfdd5fe508a623da
data/README.md CHANGED
@@ -1,6 +1,6 @@
1
1
  # MRSK
2
2
 
3
- MRSK deploys web apps in containers to servers running Docker with zero downtime. It uses the dynamic reverse-proxy Traefik to hold requests while the new application container is started and the old one is stopped. It works seamlessly across multiple hosts, using SSHKit to execute commands. It was built for Rails applications, but works with any type of web app that can be bundled with Docker.
3
+ MRSK deploys web apps anywhere from bare metal to cloud VMs using Docker with zero downtime. It uses the dynamic reverse-proxy Traefik to hold requests while the new application container is started and the old one is stopped. It works seamlessly across multiple hosts, using SSHKit to execute commands. It was built for Rails applications, but works with any type of web app that can be containerized with Docker.
4
4
 
5
5
  ## Installation
6
6
 
@@ -31,38 +31,40 @@ mrsk deploy
31
31
 
32
32
  This will:
33
33
 
34
- 1. Connect to the servers over SSH (using root by default, authenticated by your loaded ssh key)
34
+ 1. Connect to the servers over SSH (using root by default, authenticated by your ssh key)
35
35
  2. Install Docker on any server that might be missing it (using apt-get)
36
36
  3. Log into the registry both locally and remotely
37
37
  4. Build the image using the standard Dockerfile in the root of the application.
38
38
  5. Push the image to the registry.
39
- 6. Pull the image from the registry on the servers.
39
+ 6. Pull the image from the registry onto the servers.
40
40
  7. Ensure Traefik is running and accepting traffic on port 80.
41
41
  8. Ensure your app responds with `200 OK` to `GET /up`.
42
- 9. Stop any containers running a previous versions of the app.
43
- 10. Start a new container with the version of the app that matches the current git version hash.
42
+ 9. Start a new container with the version of the app that matches the current git version hash.
43
+ 10. Stop the old container running the previous version of the app.
44
44
  11. Prune unused images and stopped containers to ensure servers don't fill up.
45
45
 
46
46
  Voila! All the servers are now serving the app on port 80. If you're just running a single server, you're ready to go. If you're running multiple servers, you need to put a load balancer in front of them.
47
47
 
48
48
  ## Vision
49
49
 
50
- In the past decade+, there's been an explosion in commercial offerings that make deploying web apps easier. Heroku kicked it off with an incredible offering that stayed ahead of the competition seemingly forever. These days we have excellent alternatives like Fly.io and Render. And hosted Kubernetes is making things easier too on AWS, GCP, Digital Ocean, and elsewhere. But these are all offerings that have you renting computers in the cloud at a premium. If you want to run on our own hardware, or even just have a clear migration path to do so, you need to carefully consider how locked in you get to these commercial platforms. Preferably before the bills swallow your business whole!
50
+ In the past decade+, there's been an explosion in commercial offerings that make deploying web apps easier. Heroku kicked it off with an incredible offering that stayed ahead of the competition seemingly forever. These days we have excellent alternatives like Fly.io and Render. And hosted Kubernetes is making things easier too on AWS, GCP, Digital Ocean, and elsewhere. But these are all offerings that have you renting computers in the cloud at a premium. If you want to run on our own hardware, or even just have a clear migration path to do so in the future, you need to carefully consider how locked in you get to these commercial platforms. Preferably before the bills swallow your business whole!
51
51
 
52
- MRSK seeks to bring the advance in ergonomics pioneered by these commercial offerings to deploying web apps anywhere. Whether that's low-cost cloud options without the managed-service markup from the likes of Digital Ocean, Hetzner, OVH, etc, or it's your own colocated metal. To MRSK, it's all the same. Feed the config file a list of IP addresses with vanilla Ubuntu servers that have seen no prep beyond an added SSH key, and you'll be running in literally minutes.
52
+ MRSK seeks to bring the advance in ergonomics pioneered by these commercial offerings to deploying web apps anywhere. Whether that's low-cost cloud options without the managed-service markup from the likes of Digital Ocean, Hetzner, OVH, etc, or it's your own colocated bare metal. To MRSK, it's all the same. Feed the config file a list of IP addresses with vanilla Ubuntu servers that have seen no prep beyond an added SSH key, and you'll be running in literally minutes.
53
53
 
54
- This structure also gives you enormous portability. You can have your web app deployed on several clouds at ease like this. Or you can buy the baseline with your own hardware, then deploy to a cloud before a big seasonal spike to get more capacity. When you're not locked into a single provider from a tooling perspective, there's a lot of compelling options available.
54
+ This approach gives you enormous portability. You can have your web app deployed on several clouds at ease like this. Or you can buy the baseline with your own hardware, then deploy to a cloud before a big seasonal spike to get more capacity. When you're not locked into a single provider from a tooling perspective, there's a lot of compelling options available.
55
55
 
56
- Ultimately, MRSK is meant to compress the complexity of going to production using open source tooling that isn't tied to any commercial offering. Not to zero, though. You're probably still better off with a fully managed service if basic Linux or Docker is still difficult, but from an early stage when those concepts are familiar.
56
+ Ultimately, MRSK is meant to compress the complexity of going to production using open source tooling that isn't tied to any commercial offering. Not to zero, mind you. You're probably still better off with a fully managed service if basic Linux or Docker is still difficult, but as soon as those concepts are familiar, you'll be ready to go with MRSK.
57
57
 
58
58
  ## Why not just run Capistrano, Kubernetes or Docker Swarm?
59
59
 
60
- MRSK basically is Capistrano for Containers, which allow us to use vanilla servers as the hosts. No need to ensure that the servers have just the right version of Ruby or other dependencies you need. That all lives in the Docker image now. You can boot a brand new Ubuntu (or whatever) server, add it to the deploy servers of MRSK, and it'll be auto-provisioned with Docker, and run right away. Docker's layer caching also allows for quicker deployments with less mucking about on the server. And the images built for MRSK can be used for CI or later introspection.
60
+ MRSK basically is Capistrano for Containers, without the need to carefully prepare servers in advance. No need to ensure that the servers have just the right version of Ruby or other dependencies you need. That all lives in the Docker image now. You can boot a brand new Ubuntu (or whatever) server, add it to the list servers in MRSK, and it'll be auto-provisioned with Docker, and run right away. Docker's layer caching also speeds up deployments with less mucking about on the server. And the images built for MRSK can be used for CI or later introspection.
61
61
 
62
62
  Kubernetes is a beast. Running it yourself on your own hardware is not for the faint of heart. It's a fine option if you want to run on someone else's platform, either transparently [like Render](https://thenewstack.io/render-cloud-deployment-with-less-engineering/) or explicitly on AWS/GCP, but if you'd like the freedom to move between cloud and your own hardware, or even mix the two, MRSK is much simpler. You can see everything that's going on, it's just basic Docker commands being called.
63
63
 
64
64
  Docker Swarm is much simpler than Kubernetes, but it's still built on the same declarative model that uses state reconciliation. MRSK is intentionally designed to around imperative commands, like Capistrano.
65
65
 
66
+ Ultimately, there are a myriad of ways to deploy web apps, but this is the toolkit we're using at [37signals](https://37signals.com) to bring [HEY](https://www.hey.com) [home from the cloud](https://world.hey.com/dhh/why-we-re-leaving-the-cloud-654b47e0) without losing the advantages of modern containerization tooling.
67
+
66
68
  ## Configuration
67
69
 
68
70
  ### Using .env file to load required environment variables
@@ -74,6 +76,23 @@ MRSK_REGISTRY_PASSWORD=pw
74
76
  DB_PASSWORD=secret123
75
77
  ```
76
78
 
79
+ ### Using a generated .env file
80
+
81
+ If you're using a centralized secret store, like 1Password, you can create `.env.erb` as a template which looks up the secrets. Example of a .env.erb file:
82
+
83
+ ```erb
84
+ <% if (session_token = `op signin --account my-one-password-account --raw`.strip) != "" %># Generated by mrsk envify
85
+ GITHUB_TOKEN=<%= `gh config get -h github.com oauth_token`.strip %>
86
+ MRSK_REGISTRY_PASSWORD=<%= `op read "op://Vault/Docker Hub/password" -n --session #{session_token}` %>
87
+ RAILS_MASTER_KEY=<%= `op read "op://Vault/My App/RAILS_MASTER_SECRET" -n --session #{session_token}` %>
88
+ MYSQL_ROOT_PASSWORD=<%= `op read "op://Vault/My App/MYSQL_ROOT_PASSWORD" -n --session #{session_token}` %>
89
+ <% else raise ArgumentError, "Session token missing" end %>
90
+ ```
91
+
92
+ This template can safely be checked into git. Then everyone deploying the app can run `mrsk envify` when they setup the app for the first time or passwords change to get the correct `.env` file.
93
+
94
+ If you need separate env variables for different destinations, you can set them with `.env.destination.erb` for the template, which will generate `.env.staging` when run with `mrsk envify -d staging`.
95
+
77
96
  ### Using another registry than Docker Hub
78
97
 
79
98
  The default registry is Docker Hub, but you can change it using `registry/server`:
@@ -345,23 +364,6 @@ servers:
345
364
 
346
365
  This assumes the Cron settings are stored in `config/crontab`.
347
366
 
348
- ### Using a generated .env file
349
-
350
- If you're using a centralized secret store, like 1Password, you can create `.env.erb` as a template which looks up the secrets. Example of a .env.erb file:
351
-
352
- ```erb
353
- <% if (session_token = `op signin --account my-one-password-account --raw`.strip) != "" %># Generated by mrsk envify
354
- GITHUB_TOKEN=<%= `gh config get -h github.com oauth_token`.strip %>
355
- MRSK_REGISTRY_PASSWORD=<%= `op read "op://Vault/Docker Hub/password" -n --session #{session_token}` %>
356
- RAILS_MASTER_KEY=<%= `op read "op://Vault/My App/RAILS_MASTER_SECRET" -n --session #{session_token}` %>
357
- MYSQL_ROOT_PASSWORD=<%= `op read "op://Vault/My App/MYSQL_ROOT_PASSWORD" -n --session #{session_token}` %>
358
- <% else raise ArgumentError, "Session token missing" end %>
359
- ```
360
-
361
- This template can safely be checked into git. Then everyone deploying the app can run `mrsk envify` when they setup the app for the first time or passwords change to get the correct `.env` file.
362
-
363
- If you need separate env variables for different destinations, you can set them with `.env.destination.erb` for the template, which will generate `.env.staging` when run with `mrsk envify -d staging`.
364
-
365
367
  ### Using audit broadcasts
366
368
 
367
369
  If you'd like to broadcast audits of deploys, rollbacks, etc to a chatroom or elsewhere, you can configure the `audit_broadcast_cmd` setting with the path to a bin file that will be passed the audit line as the first argument:
@@ -153,9 +153,7 @@ class Mrsk::Cli::Accessory < Mrsk::Cli::Base
153
153
  option :confirmed, aliases: "-y", type: :boolean, default: false, desc: "Proceed without confirmation question"
154
154
  def remove(name)
155
155
  if name == "all"
156
- if options[:confirmed] || ask("This will remove all containers and images for all accessories. Are you sure?", limited_to: %w( y N ), default: "N") == "y"
157
- MRSK.accessory_names.each { |accessory_name| remove(accessory_name) }
158
- end
156
+ MRSK.accessory_names.each { |accessory_name| remove(accessory_name) }
159
157
  else
160
158
  if options[:confirmed] || ask("This will remove all containers and images for #{name}. Are you sure?", limited_to: %w( y N ), default: "N") == "y"
161
159
  with_accessory(name) do
data/lib/mrsk/cli/app.rb CHANGED
@@ -3,7 +3,7 @@ class Mrsk::Cli::App < Mrsk::Cli::Base
3
3
  def boot
4
4
  say "Get most recent version available as an image...", :magenta unless options[:version]
5
5
  using_version(options[:version] || most_recent_version_available) do |version|
6
- say "Start container with version #{version} (or reboot if already running)...", :magenta
6
+ say "Start container with version #{version} using a #{MRSK.config.readiness_delay}s readiness delay (or reboot if already running)...", :magenta
7
7
 
8
8
  cli = self
9
9
 
@@ -14,10 +14,7 @@ class Mrsk::Cli::App < Mrsk::Cli::Base
14
14
  begin
15
15
  old_version = capture_with_info(*MRSK.app.current_running_version).strip
16
16
  execute *MRSK.app.run(role: role.name)
17
-
18
- cli.say "Waiting #{MRSK.config.readiness_delay}s for app to boot...", :magenta
19
17
  sleep MRSK.config.readiness_delay
20
-
21
18
  execute *MRSK.app.stop(version: old_version), raise_on_non_zero_exit: false if old_version.present?
22
19
 
23
20
  rescue SSHKit::Command::Failed => e
data/lib/mrsk/cli/main.rb CHANGED
@@ -55,7 +55,7 @@ class Mrsk::Cli::Main < Mrsk::Cli::Base
55
55
  MRSK.version = version
56
56
 
57
57
  if container_name_available?(MRSK.config.service_with_version)
58
- say "Start version #{version}, then stop the old version...", :magenta
58
+ say "Start version #{version}, then wait #{MRSK.config.readiness_delay}s for app to boot before stopping the old version...", :magenta
59
59
 
60
60
  cli = self
61
61
 
@@ -64,7 +64,6 @@ class Mrsk::Cli::Main < Mrsk::Cli::Base
64
64
 
65
65
  execute *MRSK.app.start
66
66
 
67
- cli.say "Waiting #{MRSK.config.readiness_delay}s for app to start...", :magenta
68
67
  sleep MRSK.config.readiness_delay
69
68
 
70
69
  execute *MRSK.app.stop(version: old_version), raise_on_non_zero_exit: false
@@ -143,7 +142,7 @@ class Mrsk::Cli::Main < Mrsk::Cli::Base
143
142
  desc "remove", "Remove Traefik, app, accessories, and registry session from servers"
144
143
  option :confirmed, aliases: "-y", type: :boolean, default: false, desc: "Proceed without confirmation question"
145
144
  def remove
146
- if options[:confirmed] || ask(remove_confirmation_question, limited_to: %w( y N ), default: "N") == "y"
145
+ if options[:confirmed] || ask("This will remove all containers and images. Are you sure?", limited_to: %w( y N ), default: "N") == "y"
147
146
  invoke "mrsk:cli:traefik:remove", [], options.without(:confirmed)
148
147
  invoke "mrsk:cli:app:remove", [], options.without(:confirmed)
149
148
  invoke "mrsk:cli:accessory:remove", [ "all" ], options
@@ -186,10 +185,4 @@ class Mrsk::Cli::Main < Mrsk::Cli::Base
186
185
  on(host) { container_names = capture_with_info(*MRSK.app.list_container_names).split("\n") }
187
186
  Array(container_names).include?(container_name)
188
187
  end
189
-
190
- def remove_confirmation_question
191
- "This will remove all containers and images. " +
192
- (MRSK.config.accessories.any? ? "Including #{MRSK.config.accessories.collect(&:name).to_sentence}. " : "") +
193
- "Are you sure?"
194
- end
195
188
  end
data/lib/mrsk/version.rb CHANGED
@@ -1,3 +1,3 @@
1
1
  module Mrsk
2
- VERSION = "0.8.3"
2
+ VERSION = "0.8.4"
3
3
  end
metadata CHANGED
@@ -1,14 +1,14 @@
1
1
  --- !ruby/object:Gem::Specification
2
2
  name: mrsk
3
3
  version: !ruby/object:Gem::Version
4
- version: 0.8.3
4
+ version: 0.8.4
5
5
  platform: ruby
6
6
  authors:
7
7
  - David Heinemeier Hansson
8
8
  autorequire:
9
9
  bindir: bin
10
10
  cert_chain: []
11
- date: 2023-02-23 00:00:00.000000000 Z
11
+ date: 2023-02-27 00:00:00.000000000 Z
12
12
  dependencies:
13
13
  - !ruby/object:Gem::Dependency
14
14
  name: activesupport