Habitat at LinuxLab IT
•Transferir como PPTX, PDF•
0 gostou•125 visualizações
Version of Habitat for LinuxLab IT, December 6, Florence.
Recomendados
Mais conteúdo relacionado
Mais procurados
Semelhante a Habitat at LinuxLab IT
Semelhante a Habitat at LinuxLab IT (20)
Mais de Mandi Walls
Mais de Mandi Walls (20)
Último
Último (20)
Habitat at LinuxLab IT
- 2. Mandi Walls Technical Community Manager for EMEA @lnxchk mandi@chef.io #habitatsh http://slack.habitat.sh/ Ian Henry @Eeyun___ Habitat Community lead
- 3. Cloud Native Operations with Habitat Habitat Supervisor Habitat Builder BUILD DEPLOY MANAGE Habitat Supervisor PUBLIC ORIGIN PRIVATE ORIGIN
- 4. How Do We Run Applications? • On a computer • With an OS • And some libraries • And some configuration • And some way to start it and stop it
- 5. We’ve been moving complexity around rather than reducing it
- 6. case node['platform_family'] when 'freebsd' false when 'arch', 'debian', 'rhel', 'fedora', 'amazon' true when 'suse' node['platform_version'].to_f < 12.0 ? false : true end Ugh.
- 7. So. Habitat. • Reduce snowflakeness • Support microservices • Manage container creep • Make your workflow smoother https://www.bonanza.com/listings/Premier-Food-Storage-Containers-20-Piece-Set-Grey/443972348
- 8. What Habitat Gets You • Defer some decisions to runtime • Do clean room builds • Repeatable builds • Distro agnostic packaging system • Service runtime and discovery • Configuration exposed via API • Packages are signed by the system
- 9. What Gets Built? • Everything. Sort of. • Build your own apps from source • Decide if you want upstream binaries or source for things like runtime You don’t have to build Tomcat, but you can • For COTS, use the binaries and skip steps
- 10. Leave it to Builder • Gives you a build service • And an artifact store • Including private repos • Integrations with GitHub and Docker Hub so far CLOUD/INFRA BUILDSERVICE APPLICATION RUNTIME APPLICATIONSUPERVISION APPLICATION & DATA SERVICES SCHEDULING AND ORCHESTRATION APPLICATION CODE ARTIFACTSTORE
- 11. Hook Your GitHub Repo to Builder • Add habitat files to your repo • Hook the Habitat app to your repo • Builder can take care of building your Habitat artifacts and also integrates to Docker Hub
- 12. Configuration • Can be manipulated at runtime • Also travels with the app • Provides variable substitution and templating using handlebars http://handlebarsjs.com/
- 13. Set Defaults in Habitat – default.toml leader = false out = "out" color = "green” [tomltable] var = “val”
- 14. Habitat Builder • Build services including private repos! • You can share plans with the Depot, and other hab users share theirs • Has team namespacing • The core plans are those built by the Habitat team • https://bldr.habitat.sh/
- 15. Caveat - Internet • You can build your own stuff inside your own network, sort of, when it’s all on one machine • There may eventually be a private depot server • For now, hab and its components need internet access
- 16. Build Output • By default, it’s a hart – a compressed tarball with some metadata and a signature • You can export to other formats, like Docker containers • The hart itself it runnable
- 17. Updating Configuration at Runtime • Update all or part of the configuration while the apps are running • Send the update to a member of the mesh and they will all update sudo hab config apply --peer 172.31.2.123 container_sched_backend.stage 2 new.toml
- 18. Shortcut for common platforms: Scaffolding • Default core-built dependencies for common runtimes • Ruby and Node so farpkg_name=MY_APP pkg_origin=MY_ORIGIN pkg_version=MY_VERSION pkg_scaffolding=core/scaffolding-ruby https://www.habitat.sh/docs/concepts-scaffolding/
- 19. Join Us! • On Slack! http://slack.habitat.sh • Online! With Tutorials! https://www.habitat.sh/ • On Github! https://github.com/habitat-sh • The sample app in this talk https://github.com/lnxchk/container_sched_backend Try it out! Share your story! Get some swag!! goo.gl/WrHQTU
- 20. Other References • Summary on The New Stack https://thenewstack.io/chef-habitat-addresses-issues- moving-containers-production • Our YouTube Channel https://www.youtube.com/user/getchef • These Slides https://www.slideshare.net/lnxchk/
Notas do Editor
- On prem or in the cloud. Or in a hybrid cloud. Or in containers. Or something. On Ubuntu. Or on Red Hat. Or on CentOS if it’s not production. Or that one weird team that wants something else. OS, distribution, version? Packaging type? Initialization system type? Omg it’s systemd Where does it live? /opt /bin /company How to config? .conf .json .yml .dat What version of the language runtime??
- This is what we’ve seen over the past decade while working in configuration management. There’s always a new place to stash the complexity and hope that someone on the team understands it. Whether it’s the differences between package naming conventions in the various linux distributions your team works with or even the change over time in a single distribution, these additional changes end up becoming nodes in a network of data points that just keeps branching and branching and branching. And while we continue to invent ways to manage and rationalize the complexity, the question is, should we really do that?
- Habitat aims to take the chaos and snowflakeness out of running applications With the move towards microservices and increasingly distributed systems, taming this chaos is important The application comes first
- Single build can be run natively or in containers Run one, run many. Hook them together via the supervisor or not Don’t have to care what’s already on the target systems. Bring all your stuff with you – and only what you need Share your plan.sh files with others via depot
- Packages totally won. But added a bunch of complexity where they were meant to alleviate it Some upstream will be hard to build, and the provider may recommend packages Habitat community is helping with that
- This is the application’s configuration file, as templated for habitat. There are three overall variables “out” and “color” are configured from the environment. There are defaults that live with the habitat configuration that will be used unless a new value is passed at runtime. The “leader” variable is set based on the service. The configuration file is rewritten when an action comes to the running service – either an explicit new configuration is applied, a leader election takes place, or the application is updated to a new version