Getting rid of pain with Heroku @ BrainDev Kyiv
•Download as PPTX, PDF•
0 likes•319 views
See the whole presentation here: https://www.youtube.com/watch?time_continue=1&v=jInkHMRuS58 Thomas Vervik has explained to the audience how to get rid of strict distinication between Developers and Maintainance department, heal the pain with maintaining disks, OS patches, manually update the middleware and in generally save your time for amazing evenings with the help of Heroku.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Getting rid of pain with Heroku @ BrainDev Kyiv
Similar to Getting rid of pain with Heroku @ BrainDev Kyiv (20)
More from SeniorDevOnly
Recently uploaded
Recently uploaded (20)
Getting rid of pain with Heroku @ BrainDev Kyiv
- 1. No more Deployment Pain PaaS with Heroku
- 2. Content - SaaS < PaaS < IaaS - Toolchain as a Service - About Heroku - The Twelve Factor App - Heroku architecture - Terminology - Heroku Toolbelt - Buildpack - Confix vars - Dyno - Logplex - Add-ons
- 3. SaaS < PaaS < IaaS Software as a Service Platform as a Service Infrastructure as a Service
- 5. Toolchain as a Service - Manage your project - Trello, Jira, PivotalTracker, ... - Creating your code - Koding.com, ... - Host your code - GitHib, BitBucket, ... - Build you code
- 6. Heroku - Developed since 2007 - acquired by Salesforce.com in 2010 - One of the first PaaS providers - Built on top of Amazon`s IaaS - Started as Ruby platform - currently a polyglot platform
- 7. Heroku Terminology - Application - Procfile - Deployment - Buildpack - Slug - Dyno
- 8. Heroku architecture - Reverse Proxy by nginx - terminates SSL - forwards to cache layer - HTTP Cache by Varnish - returns cached pages immediately - forwards to routing mest - Routing Mesh written in Erlang
- 9. Set up Heroku Set up Heroku
- 10. Heroku Toolbelt - Heroku Client - CLI tool for creating and managing Heroku apps
- 11. Stack, Buildpack, Slug compiler - Stack - Operating System image (Ubuntu) - Buildpack - collection of scripts, knows how to build and execute your app - Slug compiler - build you app with buildpack, on the given stack - creates slug, an image / binary, ready to be executed on Dyno
- 12. Config variables - Variable configuration between environments - never store sensitive configuration in source repository - Will be exposed as environment variables at runtime - All dynos see the exact same set of variables at runtime - Add-ons might expose config vars
- 13. - Dyno is an isolated lightweight Linux container - Three types of dynos - web dyno, can receive HTTP traffic - worker dyno, used for background, queuing and timed jobs - one-off dyno, can run a command in a temporary dyno - Dynos are ephemeral - shared state requires external data store Dyno and Dyno Management
- 14. Logplex - Collates and distributes log entries - all application dynos - add-ons and other components - Routes messages from sources to drains - source: any process that might want to emit log entries - drain: any network service that want to consume log entries - Limited log entry buffer
- 15. Add-ons - Provided as services by Heroku and third parties - add-ons available from market place - starting from free plans to monthly subscriptions - Add-on providers are responsible for their add-ons - integrate via config vars - some contain external web user interface
- 16. Preboot Production cloud application without zero downtime deployments... - Changes the dyno start behavior to `blue - green` - ensures new dynos are started and ready to receive traffic - requires at least 2 dynos - two versions of application dynos running at the same time
- 17. Pipelines - Pipelines help to solve complexity of multi-environment - dev, test , staging, production, … - Pipeline manages application slug - diff between current and downstream app - promote slug to downstream target
- 18. - I. Codebase - One codebase tracked in revision control, many deploys - II. Dependencies - Explicitly declare and isolate dependencies - III. Config - Store config in the environment - IV. Backing Services - Treat backing services as attached resources - V. Build, release, run - Strictly separate build and run stages - VI. Processes - Execute the app as one or more stateless processes - VII. Port binding - Export services via port binding The Twelve-Factor App - 12factor.net
- 19. Demo - Deploy BrainDev Spring Boot app 1. Create App Heroku a. heroku apps:create braindev-demo-staging --remote staging ---buildpack https://github.com/heroku/heroku-buildpack-scala b. git remote add staging https://git.heroku.com/braindev-demo-staging.git 2. Publish a. git push staging master 3. See log a. heroku logs -t 4. Set config
- 20. Thank you
Editor's Notes
- Welcome Deploying application, own server, VPS install OS, dependencies, deploy script, document properterian solution server maintained, installing OS security patches, update JVM, logging rolling, tmp files filling disk Simpler solution? Yes. Welcome to Platform as a Service! Welcome to this presentation about Heroku. If you have ever had the responbility of deploying and managing an application in production, using your own server, or a VPS, you know how much pain it is setup the server, install dependencies (maven/gradle/application server), creating/maintaining deployment scripts, documenting your often propertiarian solution. And after its out in production, the server has to be maintained, by installing OS security patches, update the Java Virtual Machine, making sure logs are rolling correctly, that temporary files arent filling up the disk, etc etc etc. And so the pain goes on. Isnt there a simpler way to solve these issues? Yes, there are. Welcome to Platform as a Service!
- Here`s today content. Im gonna describe the different types of services and define some terminology, Lets jump straight into it.
- Lets first define some termonology. Software as a Service Applications for end-users delivered on-demand Platform as a Service Operating system, runtime environment and middleware Infrastructure as a Service servers, virtualization, storage and networking
- Here`s a diagram showing the layers on a server. The first diagram shows what you needed to set up in the old days with an own dedicated server. The second is what a IaaS include, Then a provider, like Amazon AWS, are setting up the infrastructure for you, and give you access to the machine (typically a VPS) with SSH / OS. So we see that if you have IaaS, the provider will give the first four layers, and then you set up the OS and everything you self. This is a typical VPS setup, like AWS EC2 and similar. Usually they also provide OS for you, but I see they havent mentioned that here. With Plaform as a Service, which Heroku is, also the middleware and runtime environment is provided for you, and the only thing you need to do is to provide your application and configuration settings for it. Software as a Service, thats how it look if someone else has set it up for you. Like Google Drive and similar.
- Now adays all of the tools you need to do development and deploy you application, can be found in the cloud. You use Trello, Jira, PivotalTracker in the cloud. You can set up the developer environment with services like koding.com You host your code in GitHub or Bitbucket, which enables you to do many exiting integrations with a click (will show on Heroku) You build and executes tests with Continues Integration services in the cloud, like Travis CI, GreenHouse You can test your code on on services like BrowserStack, Source Labs, etc And you can distribute your code on Maven Central, Docker Hub, npm (node package manager), etc
- Short about Heroku. Started in 2007, aquired by salesforce in 2014. One of the first PaaS provides Is built in top of Amazon`s IssS
- Lets define some termonology: Application - source code and description of any dependencies Procfile - list of process types - named commands to be executed Deployment - sending application to Heroku using Git or Dropbox Buildpack - set of scripts, that knows how to compile and build you code from your source / GIT repo, output is a slug Slug - bundle of application, language runtime and compilation output Dyno - isolated, virtualized Linux container which executes your application, which is the slug Config var - configuration data hosted independently of source code. Its basically environment variables. Release - append-only ledger of slugs, config vars and add-ons Add-on - easily attachable third party cloud services, like database, sms, email, monitoring, etc Logplex - collates logs from all running dynos and other components. Look at it as an event stream.
- Not gonna talk to much about this, just showing a diagram on how the Heroku architecture looks like.
- So, to get started with Heroku, the first thing you do, after having created an account, is to install the Heroku Toolbelt. Its a command line tool which enables you to create, deploy and administrate you app on Heroku/
- A stack is an operating system image curated by Heroku. There are two stacks, based both on Ubuntu, just different versions of Ubuntu. This will be the OS layer in the diagram earlier. A buildpack is a collection of scripts which knows how to build and execute your application. Are seperate buildpacks for different environments, like Java, Scala, Ruby, PHP, etc. This will be the middleware and runtime layer in the diagram earlier. The slug compiler compiles and build you code with the given buildpack, and the output will be a Slug, an image if you`d like, which can be executed on a Dyno
- So now we have a slug, an image with our application. That image/slug can now be deployed to an envirnonment. But different enviornments have different properties, like staging / production, etc. To set configurations and environment variables, we use the heroku config.
- A dyno is a lightweight Linux container that runs a single user-specified command. The slug just created contains you pre-packaged application. The config modules enablaes you to set specific environment configurations for your server. The dyno is the linux process which execute your code. There are three types of dynos: Web dyno - which binds to a port so it can accept inbound requests Worker dyno: which executes background jobs, typically batch jobs. One-off dyno. Not gonna go in to that here The dyno manager is the component which starts / stops / scales dynoes. You can tell the dyno manager, from command line, to start up new dynos (horizontal scaling)
- Heroku uses ephemeral filesystem, which means the file system shouldnt be “trusted”. The file system will disapare if the dyno is shut down, or undergoes maintenance. Therefore, things like logs, should be thought about like streams. Heroku Logplex has a concept of a source - any process that might want to emit log entries -, and drain: any network service that want to cosume log entries. I think its the buildpack which determines what are your logs, and streams them to Heroku Logplex so it becomes available to you through the heroku log command.
- Add-ons are services which you can add to you application, like Database, Reddis, logging, proxy, monitoring, sms, email, etc.
- A pipeline is a group of Heroku apps that share the same codebase. Apps in a pipeline are grouped into “review”, “development”, “staging”, and “production” stages representing different deployment steps in a continuous delivery workflow. A code change will typically be deployed first to a pull request, which automatically creates a review app, then merged into master which isautomatically deployed to staging for further testing before promotion to production where the new feature will be available to end users of the app. The pipelines overview page helps you visualize this flow, as well as meta information about the status of each stage. For example, you can see if your production app is running different code than staging.
- I. Codebase - One codebase tracked in revision control, many deploys II. Dependencies - Explicitly declare and isolate dependencies III. Config - Store config in the environment IV. Backing Services - Treat backing services as attached resources V. Build, release, run - Strictly separate build and run stages VI. Processes - Execute the app as one or more stateless processes VII. Port binding - Export services via port binding VIII. Concurrency - Scale out via the process model IX. Disposability - Maximize robustness with fast startup and graceful shutdown X. Dev/prod parity - Keep development, staging, and production as similar as possible XI. Logs - Treat logs as event streams XII. Admin processes - Run admin/management tasks as one-off processes
- Prerequist. Play Application, source code GitHub: https://github.com/tha022/braindevkiev heroku apps:create braindev-demo-staging --remote staging heroku buildpacks heroku buildpacks:set https://github.com/heroku/heroku-buildpack-scala heroku open git push staging master