Deployment
Deploying any Rails application to any cloud in minutes

Summarized using AI

Deploying any Rails application to any cloud in minutes

Khash Sajadi • April 17, 2018 • Pittsburgh, PA

In this video titled "Deploying any Rails application to any cloud in minutes" presented by Khash Sajadi at RailsConf 2018, the speaker discusses efficient ways to deploy and manage Rails applications on various cloud providers without being tied to any particular PaaS. Sajadi highlights how traditional PaaS solutions like Heroku can be limiting due to factors such as rising costs, lack of flexibility, vendor lock-in, and difficulties in seamlessly integrating new technologies. To address these challenges, the speaker introduces Cloud 66, a platform designed to simplify Rails deployment while giving developers greater control over their cloud infrastructure.

Key points discussed in the video include:

- Challenges of PaaS: Sajadi describes a common phenomenon termed the "PaaS cliff", where developers initially favor services like Heroku but later move away due to high costs and limited flexibility.

- Cloud 66 Features: The platform supports the provisioning and deployment of Rails applications directly from code repositories to chosen cloud providers, allowing users to maintain control of configurations, costs, and technology stacks.

- Ease of Use: Sajadi demonstrates the streamlined deployment process, where developers can connect their Git repositories and cloud accounts, automatically configuring and provisioning servers based on application requirements.

- Scalability and Backup: The deployment process includes options for scaling databases, setting up replication, and managing off-site backups seamlessly, further reducing the operational burden on developer teams.

- Customizability: Developers can use this platform to customize environments (like Nginx setups) and manage deployments while still benefiting from best practices.

- Monitoring and Security: The platform also integrates monitoring tools and advanced security measures to safeguard applications and ensure smooth operations.

- Community and Support: The speaker encourages the audience to visit their booth for further queries and hands-on demonstrations, indicating an emphasis on community engagement.

The talk concludes with a reaffirmation of Cloud 66's capability to provide a straightforward, customizable, and powerful solution for Rails application deployment, freeing developers from the constraints of traditional PaaS providers.

Deploying any Rails application to any cloud in minutes
Khash Sajadi • April 17, 2018 • Pittsburgh, PA

Deploying any Rails application to any cloud in minutes by Khash Sajadi

Let us show you the easiest way to build, deploy and manage any Rails application on any cloud provider and under your own cloud account. We will also show you how to scale your databases, setup database replication and add off-site backups to your databases with extreme simplicity. Find out how to spend less time configuring boxes, and more time developing great web apps!

This is a sponsored talk by Cloud 66.

RailsConf 2018

00:00:11.090 Thank you very much for coming. I know that the deployment of Rails is not particularly interesting, exciting, or nearly as cool as Kubernetes and containers or Docker nowadays.
00:00:17.310 So I'm going to get that out of the way. But today, I thought I would show you what we've built, what we can offer to help you and your team with Rails deployment.
00:00:31.320 Before I do that, there's a little history to discuss regarding why we embarked on this project, and why we believe it addresses a significant problem.
00:00:39.030 We already had Capistrano; what's wrong with that? How did we get to where we are today?
00:00:51.059 Cloud 66 started as a different company with a different name, doing a different thing. We were a Rails shop, and like many others, we began with a PaaS provider.
00:01:05.460 Our first choice was Heroku; we were their customers. I've worked in both large and small companies, and every time I initiated a project on Heroku, I eventually left.
00:01:20.640 The question for me was: why do we all love PaaS platforms like Engine Yard or Heroku? We truly appreciate them, but why do we all end up leaving?
00:01:34.710 As a different company, we began asking others this question when we thought about leaving PaaS. So, let me take a risk and ask you: who here has started with something on Heroku?
00:01:49.049 How many projects have you started with Heroku, and are you still using it, or have you moved elsewhere? It's an interesting point to consider. This audience might be slightly biased, but what we find is a situation I call the 'PaaS cliff.' We all start with PaaS, but we tend to fall off that cliff relatively quickly.
00:02:19.880 People give various reasons for leaving; cost is often cited. This seems odd, as if you're doing well, you should be able to pay the bills. But sometimes it relates to aspects like flexibility or vendor lock-in.
00:02:43.020 I've even encountered a situation at a bank where we wanted to run a proof of concept and presented it to colleagues at Heroku. The excitement was palpable, but then operations teams took over and insisted on managing things in a different way, which discouraged me from using PaaS again.
00:03:02.370 So, we made the leap and found ourselves building a different business. This is what our journey looked like; we jumped into a space filled with complexities.
00:03:11.130 Today, instead of focusing purely on this history, I want to demonstrate what we have built and the journey we traversed to be able to deploy a Rails application. Our aim is to replicate the rewarding experience of using a PaaS provider while maintaining control of costs and benefiting from market price reductions.
00:03:47.910 We also wanted to experiment with new technologies, like time series databases, which are essential as our developers seek creative solutions. The challenge arises when adding external components leads to 'snowflakes'—unique setups that complicate the management and reliability of our systems.
00:04:23.130 When a major provider like Amazon experiences an issue, and everyone is told to shut down their EC2 instance and restart it, a process that should supposedly be straightforward often becomes a struggle. So, let me show you a quick demo of what we've accomplished.
00:04:54.590 This is the Cloud 66 dashboard. On the left, you can see a container-based Kubernetes ramp application that we commonly demonstrate when discussing our container products. We have four products: two focusing on Rails and Node, while the other two, Skycap and Maestro, help build and deploy applications on Kubernetes.
00:05:44.060 Today, I want to focus primarily on the Rails product. Our goal when designing this was to streamline the process from code to production.
00:06:07.240 Imagine the conventional PaaS experience when you have your code that easily transitions into production with every commit triggering a build process. We envisioned a slight modification to that model.
00:06:25.380 We connect your git repository to pull the code, and on the other hand, we integrate with your cloud provider of choice under your own account. We then provision and configure the necessary servers to deploy your application.
00:06:48.710 But how do we know what type of services are required? It's not a one-size-fits-all situation. If your Rails application uses Memcached and Redis, should each service run on individual servers, or do we combine them?
00:07:16.870 This is how our workflow appears. Selecting a Rails application, I can choose from one of our sample projects. This simple Rails application exemplifies our configuration.
00:07:25.539 It utilizes MySQL, while you might notice a Docker file included that's not used in this demo. We also include a classic 66 folder that contains necessary environment variables, but you won't necessarily need to use them for this application.
00:08:04.960 I will start deploying this by using the Git repository URL. As it's a public repository, I'll connect to it via HTTP using the master branch, calling it Rails Conf 3.
00:08:14.050 I'm running a live demo, so I hope the demo gods will be in my favor. Should I encounter an issue with Wi-Fi, I'll have to improvise.
00:08:32.079 Now, we're connecting to the Git repository. We retrieve the code and examine configuration files like your database config, alongside other guidelines integrated into the repository.
00:08:54.660 The great thing about Rails is the convention over configuration approach, allowing us to deduce various aspects from those conventions.
00:09:17.070 For instance, this application is specified to run in production using Rails 4.2.8 and Ruby 2.1.5. We configured the default setup to run with Nginx and Passenger, with the possibility to select Unicorn if preferred.
00:09:54.197 This simple configuration indicates we are using MySQL in the backend. This information is accessible through the configuration files.
00:10:09.360 For a classic 66 deployment, we support post-deployment hooks to streamline your processes instead of relying on manual installation and scripting.
00:10:37.960 This includes backend jobs that run, ensuring swift deployments while we leverage our own experience to optimize classic six.
00:11:01.840 Customers in over 110 countries use our platform, with approximately 600 developers actively using Cloud 66. They manage their deployments, completing around 5,000 to 6,000 deployments across the board.
00:11:22.849 This ongoing activity means that Sidekiq is consistently active.
00:11:33.579 This need prompted us to build a solid deployment process that works efficiently, addressing significant pain points.
00:11:42.920 Regarding job files that facilitate commands, we see great value in utilizing Rails as a framework with baked-in conventions. You can add environment variables and settings as needed.
00:12:02.520 You can lock your Ruby version in your Gemfile, and if not locked, the system will present you with drop-down choices.
00:12:24.330 Our understanding of Rails is deep, so you can easily add specific configurations around assets, pipeline, DB schema loads, and more.
00:12:39.220 Any cloud provider can be integrated; you simply need to link your chosen service account. Whether it's AWS, DigitalOcean, or another, you just need the authentication credentials and API keys.
00:12:54.420 If you run on other bare metal providers outside of Packet, a simple registration process allows you to include them seamlessly in our configuration.
00:13:11.230 Each installation involves selecting the installation region and server types. You can also specify how to distribute your app across various cloud resources.
00:13:38.450 For example, your Rails server can be on one server, while MySQL can be on another, thereby promoting good practices even for demo purposes.
00:14:01.320 The configuration allows flexibility, letting you scale your application as required, without needing to specify everything upfront.
00:14:32.910 Once everything is set, we can deploy to DigitalOcean and kick off server creation instantly. Each server is given an animal name and can be renamed upon creation.
00:14:53.180 Behind the scenes, we efficiently set up the server with the chosen configurations, verifying compatibility and version updates, ensuring everything is installed before proceeding.
00:15:28.540 All necessary packages, security updates, and unique configurations are systematically applied, ensuring the server runs as required as soon as it's ready.
00:15:44.460 The server's setup includes specifics like public and private IP addresses, firewall configurations, and the installation of necessary management packages.
00:16:07.350 As demonstrated by my setup, I've established a Rails server, MySQL server, and a worker process intended to handle job queues.
00:16:40.180 We ensure everything feeds into a single application environment, facilitating easy management.
00:16:59.960 The cloud service not only provisions servers but also configures them for the application seamlessly, allowing straightforward scaling and adjustment for your systems.
00:17:23.390 Once the application stack is created, load balancers can be integrated to allow for efficient traffic management.
00:17:52.820 In addition, our platform allows users to set up automatic backup controls, where entire database systems can be backed up concurrently.
00:18:30.000 These backups are compressed, encrypted, and stored in the closest S3 region, fulfilling data residency requirements.
00:18:49.210 You can choose the frequency of backups and the type—incremental or full snapshots.
00:19:17.360 Moreover, this system can restore data in a time-efficient manner, allowing users to revert their applications to a previous state.
00:19:46.540 You can also seamlessly use your own databases and load balancers if preferred.
00:20:08.310 With regard to SSL certificates, our platform can manage certificate integration easily, adjusting configurations automatically based on the deployment settings.
00:20:27.500 Our system automates SSL renewals and configurations without interrupting applications, ensuring a stress-free management process.
00:20:43.950 As part of this continuous evolution, we support a backup verification process to ensure integrity and accessibility of all backups made from your system.
00:21:01.950 This can help assure business continuity by verifying that backups are indeed accessible when they're most needed.
00:21:18.820 Furthermore, our deployment history gives you a comprehensive view of all updates with appropriate commit history.
00:21:38.530 Being aware of configuration files makes managing your operational environment simple and effective.
00:21:54.350 We dedicate efforts to ensure that while still enjoying the automation that classic six brings, awareness and access ensure security and operational integrity.
00:22:07.840 Consequently, tailored monitoring allows you to track your environment live, providing insights on performance across various components.
00:22:31.520 We continuously receive data from individual servers regarding traffic security and access attempts to promptly alert users when any anomalies occur.
00:22:55.180 Real-time alerts sent via various notification methods such as Slack, ensure the teams are always informed.
00:23:14.680 With added logging features operational teams can access terraced logs without needing to set up an external logging solution.
00:23:31.410 Live logs offer immediate insight into deployment actions or application errors, enabling quick responses without additional overhead.
00:23:55.960 As I navigate my stack, connectivity issues may arise, and it's critical to be prepared for troubleshooting.
00:24:19.090 The health status scores keep track of components, alerting you if anything may require attention or immediate action.
00:24:45.460 Every action's logging enables you to verify what occurs within the operational landscape, ensuring accountability and transparency.
00:25:04.670 In conclusion, all fundamental aspects of these processes serve to enhance operational efficiency and security.
00:25:28.120 As we continue to build our ecosystem, we are considerably focused on user feedback for improvements.
00:25:55.650 Does anyone have any questions before we move forward? I'm happy to address any inquiries regarding our approach.
00:26:20.950 Thank you very much for your time. I sincerely hope you enjoyed the presentation, and I invite you to visit our demo booth to explore more along with further inquiries.
Explore all talks recorded at RailsConf 2018
+98