LocalStack to framework udostępniający łatwe w użyciu mocki usług stosu AWS. Podczas prezentacji Maciej skorzystał z serwisu zbudowanego z użyciem serverlessowego Boilerplate autorstwa The Software House oraz skorzystał z takich usług AWS jak API Gateway, DynamoDB, Lambda, StepFunctions czy SQS. Następnie omówił podejście do testowania rozwiązania. Dzięki prezentacji możecie poznać wady i zalety LocalStack. A na koniec Maciej pokazuje przepływ testowy w GitHub Actions, który zwiększy pewność przyszłych zmian.
Bartosz Tkaczewski: Zarządzanie kontenerami może być proste, a nawet przyjemne. Na prezentacji dowiesz się, jak szybko uruchomić klaster na chmurze Googla oraz jak w szybki i wygodny sposób wdrożyć aplikację. Nie zabraknie liźnięcia technikaliów – tych podstawowych i tych nie do końca oczywistych. Aby wilk był syty, a i owca nadal beczała.
Link do repozytorium: https://github.com/tkaczu/uszanowanko-k8s
Kainos Tech Space #1 : DevOps : Artur Senk - Jenkins, najważniejsze narzędzie...Kainos Polska
O Jenkinsie lub podobnych narzędziach słyszał chyba każdy deweloper i każdy ops. Dla jednych i drugich jest to bardzo często główne okno, przez które widać co się dzieje w projekcie jak i miejsce, gdzie można mieć bezpośredni wpływ na każdy etap kodu „przepływającego” z maszyn deweloperów na produkcję. O sile Jenkinsa stanowi mnogość wszelkiego rodzaju dodatków i nieskończona możliwość ich konfiguracji. Na przykładach z obecnego projektu chcę pokazać, jakie konkretnie pluginy i rozwiązania ułatwiają nam życie.
Testy wydajnościowe to nie tylko JMeter. Podobnie jak w przypadku testów automatycznych, liczba frameworków do badania wydajności stale rośnie. Poza wprowadzeniem w tematykę testów wydajnościowych, w trakcie prezentacji przyjrzymy się ich implementacji we frameworku k6. Opowiemy również dlaczego w The Software House postawiliśmy na jego wybór i jak dzięki prostym skryptom testowym zoptymalizowaliśmy kilka naszych projektów.
Adrian Chlubek: Dowiemy się, czym jest Swoole, w jakim celu został stworzony i jakie funkcjonalności oferuje – wszystko to na żywych przykładach. Przede wszystkim jednak spróbujemy odpowiedzieć sobie na pytanie: czy używanie Swoole ma sens?
Repozytorium z przykładami: https://github.com/achlubek/swoole_experiments
Dokumentacja Swoole: https://www.swoole.co.uk/docs/
Czym tak naprawdę jest deployment, co może pójść nie tak i w jaki sposób możemy się przed tym zabezpieczyć, korzystając z Kubernetesa i jego ekosystemu. Zaczniemy od tego, jakie są rodzaje deploymentów, po czym wspomnimy dlaczego należy uważac z healthcheckami. Czym jest Circuit Breaker i jak może nam pomóc? Jak wygląda Canary Analysis w praktyce? Odpowiedzi na te wszystkie pytania z pewnością sprawią, że przycisk “Deploy To Production” przestanie być taki straszny.
Trudne jest zarządzanie własną infrastrukturą. Trochę prościej jest użyć chmury, jednak wciąż czeka nas sporo konfiguracji. A co, gdyby wszystkie potrzebne usługi skonfigurowały się “same”, a nam pozostało tylko doglądanie całości? AWS Elastic Beanstalk umożliwia zautomatyzowane skonfigurowanie środowiska w chmurze AWS pod konkretne aplikacje. Można dzięki niemu wygodnie uruchomić Dockerowe kontenery i właśnie tym zajmiemy się na prezentacji. Opowiemy pokrótce jak działa Beanstalk i przeprowadzimy deployment przykładowego programu). I to wszystko bez zastanawiania się nad infrastrukturalnymi szczegółami.
Adrian Chlubek: Czy PHP jest gotowy na websockety? Czy architektura samego języka nie stoi na przeszkodzie? Zobaczymy jakie mamy możliwości pracy z Websocketami, porównamy trzy popularne rozwiązania umożliwiające taką komunikację, a następnie odpowiemy sobie na pytanie – czy to ma sens?
O mojej skrzynce z narzędziami, w której znajdziemy: #ansible #terraform #packer #docker #vagrant #capistrano.
Video: https://www.youtube.com/watch?v=fPZ7JZJGPTE
Wykład ze styczniowego spotkania grupy UW@IT pt. "Ansible w praktyce".
Ansible jest narzędziem wykorzystywanym do automatyzacji codziennych działań związanych z tworzeniem oraz utrzymaniem infrastruktury IT.
2019.10.08 share con365 2019 open source in azure devops, on the example open...Janusz Nowak
Janusz Nowak
Open Source in Azure DevOps, on the example Open API for Azure Functions
How to create open source public project in Azure DevOps using it all benefits, creating open source library for generating Open API/Swagger definition for Azure Function and showing what goods it is bringing. http://www.sharecon365.pl/sessions/ 2019
Core Web Vitals to metryki przygotowane przez Google w celu pomiaru wydajności aplikacji oraz User Experience. Są one składowymi wyniku “Performance” obliczanego przez narzędzie Lighthouse. W swojej prezentacji Marcin przybliży temat poszczególnych metryk, a następnie na kilku przykładach postaram się zaprezentować problemy wpływające na niższy wynik oraz jak sobie z nimi poradzić. Całość prezentacji opierać się będzie na prostej aplikacji Next.js, której wynik będziemy starać się poprawić, korzystając z kilku ciekawych narzędzi.
Nowe, potężne narzędzia do tworzenia stron internetowych pojawiają się niemal codziennie. My w zespole postanowiliśmy jednak cofnąć się o krok i postawić na to co proste, ale użyteczne. Efekt? Korzyści dla zespołu i dla klienta. Podczas prezentacji opowiem o tym, co zyskaliśmy oraz wprowadzę słuchaczy w świat Hugo – nowoczesnego generatora stron statycznych.
Este documento apresenta as ementas semanais de uma creche e jardim-de-infância, incluindo os almoços, lanches e reforços servidos às crianças de segunda a sexta-feira, com variações nas refeições ao longo das semanas.
On May 19, 2016 I hosted a workshop at Stanford's Codex Center about ways to make legal data more open and accessible for computation. These are the slides from my presentation framing the issue.
Lee Rainie, director of internet and technology research at Pew Research Center, discussed recent findings about the prevalence and impact of online harassment at the Cyber Health and Safety Virtual Summit: 41% of American adults have been harassed online and 66% have witnessed harassment. The findings come from the Center’s recent report on these issues.
Harry Surden - Artificial Intelligence and Law OverviewHarry Surden
This document provides an overview of artificial intelligence. It defines AI as using computers to solve problems or make automated decisions for tasks typically requiring human intelligence. The two major AI techniques are logic and rules-based approaches, and machine learning based approaches. Machine learning algorithms find patterns in data to infer rules and improve over time. While AI is limited and cannot achieve human-level abstract reasoning, pattern-based machine learning is powerful for automation and many tasks through proxies without requiring true intelligence. Successful AI systems are often hybrids of the approaches or work with human intelligence.
2017 holiday survey: An annual analysis of the peak shopping seasonDeloitte United States
Holiday retail spending is bucking trends this season with only one-third of holiday budgets going toward gifts. Online spending is expected to exceed in-store for the first time. In addition to gifts for others this year, spending on experiences and self-gifting increased. Explore more consumer spending trends in our 32nd annual holiday survey. For more: http://deloi.tt/2yH1VAn.
The document summarizes 10 key facts about the future of work: 1) Jobs are becoming more knowledge-based, requiring skills like analytical thinking. 2) Employment has grown most in healthcare, education, and professional services. 3) Automation is replacing many traditional jobs, with estimates that 47-50% of current jobs could be automated. 4) People see other jobs as more at risk of automation than their own. 5) More people express worry than optimism about automation's impact. 6) Workers see technology as more positively impacting their careers. 7) Higher-educated workers report greater benefits from technology. 8) Skills in technology, communication, and lifelong learning are seen as most important for the future. 9)
Google continues to dominate search and increase its share. According to data, Google's core search increased 5.9% from October 2016 to May 2017 while its closest competitors like Yahoo and Bing declined. Google distributes search traffic relatively evenly across sites while Facebook and YouTube tend to concentrate traffic on very large sites. Reddit and YouTube send the majority of their referral traffic to just a handful of top sites.
This document provides a summary of fundraising rounds for AI and data startups in Europe in 2016. Some key findings include:
- Over 270 startups raised $774 million in 2016, up from $583 million in 2015.
- The average funding round was $3.7 million.
- France and the UK led fundraising totals, with 108 startups in the UK raising $188 million and 37 startups in France raising $118 million.
- Early stage investments boomed, with $215 million invested in 170 early stage startups.
- In 2016, focus shifted from marketing applications to technologies using natural language processing, speech recognition and other AI techniques, as well as applications in healthcare, agriculture and other industries
AI and Machine Learning Demystified by Carol Smith at Midwest UX 2017Carol Smith
What is machine learning? Is UX relevant in the age of artificial intelligence (AI)? How can I take advantage of cognitive computing? Get answers to these questions and learn about the implications for your work in this session. Carol will help you understand at a basic level how these systems are built and what is required to get insights from them. Carol will present examples of how machine learning is already being used and explore the ethical challenges inherent in creating AI. You will walk away with an awareness of the weaknesses of AI and the knowledge of how these systems work.
Wprowadzenie do Kubernetesa oraz omówieni korzyści K8S w kontekście mojego doświadczenia z dwóch startupów, jeden z branży mobile ecommerce i jeden FinTech.
Aplikacje natywne dla Kubernetes z wykorzystaniem OpenShift Serverless - Wars...Chris Suszyński
Czy Serverless to uruchamianie prostych funkcji w chmurze? FaaS? To znacznie więcej! Serverless odnosi się do koncepcji budowania i uruchamiania aplikacji, które nie wymagają zarządzania serwerami.
Opisuje model wdrażania, w którym aplikacje, spakowane jako jedna lub więcej funkcji, są przesyłane na platformę, a następnie uruchamiane, skalowane i rozliczane w odpowiedzi na dokładnie potrzebne zapotrzebowanie w danym momencie.
Jak korzystać z Knative zarówno w Kubernetes, jak i na platformie OpenShift. Mam nadzieję, że zrozumiemy, dlaczego Twoja organizacja powinna rozważyć użycie Knative jako jednego z podstawowych modeli wdrażania w czasach chmury hybrydowej. Wszystko to w duchu otwartego oprogramowania!
Kivy to biblioteka pythonowa do tworzenia wieloplatformowych aplikacji GUI.
Samples: https://github.com/daftcode/pywaw_kivy_na_androidzie/blob/master/README.md
CONFidence 2018: "Small money, a lot of bugs" - Large scale bughunting dla ty...PROIDEA
W prezentacji zostanie przedstawione podejście do problemu automatycznego wyszukiwania podatności bez posiadania znacznej mocy obliczeniowej (własnej farmy serwerów) które pomogło w ujawnieniu prawie 400 różnych błędów w oprogramowaniu open-source (w tym ~110 podatności z CVE) w okresie jednego roku. Pokazane zostaną procesy zwiększające efektywność fuzzingu w chmurze oraz autorski system (codename: Cloudfuzz) wspomagający deduplikację crashy, analizę błędów, zarządzanie korpusem oraz serwerami. Omówię także najpoważniejsze błędy odkryte za pomocą systemu, a także widoki na rozwój projektu.
Jak zbudować aplikacje z wykorzystaniem funkcjonalności windows server 2016...Lukasz Kaluzny
Zagadnienia:
Nowe funkcjonalności Microsoft Windows Server 2016 w kontekście budowy aplikacji typu cloud-native:
Zastosowanie Nano Servera, czyli odchudzonej wersji Windows Server 2016, oszczędniej korzystającej z zasobów IT.
Uruchamianie na Nano Serwerach WS2016 aplikacji napisanych w .NET, Javie, Pythonie (Django) czy JavaScript (Node.js).
Migracja - bez konieczności zmiany kodu - istniejących aplikacji do architektury opartej o kontenery. Kontenery to rozwiązania oparte na szybkiej wirtualizacji na poziomie procesów. Nie tworzą dodatkowych instancji jądra systemu operacyjnego. Na tym samym hoście można uruchomić większą ilość kontenerów niż maszyn wirtualnych. Uruchamianie i zamykanie kontenera jest też znacznie szybsze, niż uruchamianie i zamykanie maszyny wirtualnej.
Wspólna praca developerów i administratorów nad produktem, czyli DevOps z wykorzystaniem Windows Server 2016 i Visual Studio Team Services w chmurze Azure. Automatyczne budowanie obrazów kontenerów dla każdego nowego kodu i wdrażania ich w różne środowiska
Łatwiejsze zarządzanie obciążeniami aplikacji pomiędzy zasobami we własnej infrastrukturze i w chmurze Azure dzięki WS2016 oraz Azure Service Fabric.
Funkcjonalności Windows Server 2016 powstałe z myślą o wygodzie administratorów:
Nowa wersja PowerShell 5.0 - przynosząca lepsze funkcjonowanie powłoki linii poleceń oraz udoskonalony język skryptowy,
Azure Remote Server Management Tools – zdalne zarządzanie Nano i Windows Server 2016 z Azure,
PowerShell Direct,
Nested Virtualization jako wsparcie ułatwienia nauki i testów.
Wbrew powszechnym opiniom, nie tak prosto jest zrobić dobre Code Review. Robione w pośpiechu, tylko po to by je "odbębnić", często stwarza więcej szkody niż pożytku. Opowiem wam dlaczego code review jest ważne i jak wykorzystać ten proces aby upewnić się, że napisany kod jest najwyższej jakości. Będę nie tylko mówił o tym kto powinien robić code reviews, i dla kogo, jakie informacje są potrzebne do przeprowadzenia skutecznego code review, ale także jak zrobić dobre code review w najkrótszym możliwym czasie.
Piątek z XSolve - TravisCI & Continuous DeliveryXSolve
Maciej Papież, Software Developer w XSolve, w prezentacji na temat jak najprostszej implementacji Continuous Delivery/Deployment.
W prezentacji znajdują się informacji na temat prostego pipeline'u CD, TravisCI i praktycznego podejścia do AWS CodeDeploy.
Prezentacja będzie zawierała luźne anegdoty i doświadczenia z używania kontenerów dockera w produkcji, również do hostowania aplikacji PHP. Sposoby budowania kontenerów, typowe problemy deploymentu.
GET.NET - Osiołkowi w żłobie dano, czyli o tym jak hostować aplikacje na Mic...Michal Furmankiewicz
Azure oferuje wiele platform na których możesz uruchomić swoją aplikację. Każda ma swoje zalety i wady. Zrobiłem przegląd tych platform dla Ciebie. W prezentacji wyrażam swoją prywatną opinię.
This document discusses the history and development of Docker. It notes that Docker was originally created at dotCloud as the engine for their Platform as a Service (PaaS), but in 2013 as PaaS times were hard, Docker was open sourced. Docker was based on LXC and created for a single purpose. dotCloud then pivoted to create Docker Inc. and make Docker their main product. The document also discusses Docker 1.11's integration with runC and systemd, as well as the transition to using the Open Container Initiative specification.
Programowanie AWSa z CLI, boto, Ansiblem i libcloudemMaciej Lasyk
The document describes a session that demonstrates how to program AWS using the AWS CLI, Boto, and Ansible. It provides an agenda for the session that includes a short AWS introduction, demonstrations of the AWS console, AWS CLI, AWS shell, Boto library, Ansible configuration management tool, and Libcloud library. Contact information is also provided for learning more about AWS programming and joining the training organization.
This document discusses Linux security and SELinux. It provides an overview of SELinux and how it works to provide mandatory access control on Linux systems. It discusses how SELinux labels processes and files to confine programs and prevent unauthorized access. It also discusses using SELinux with Docker containers to provide security isolation between containers.
Under the Dome (of failure driven pipeline)Maciej Lasyk
The document discusses various topics related to DevOps including:
1. Different types of shells (login, non-login, interactive, non-interactive, su, sudo su, sudo -i, sudo /bin/bash, sudo -s) and how they affect environment variables and profile files.
2. Stories of organizational "anti-types" that go against DevOps principles like not seeing the need for operations teams.
3. How automation, consistency, and reducing errors leads to stable environments and less unplanned work, allowing teams to focus on delivery.
This document discusses integrating security into DevOps practices through continuous delivery. It proposes including security automation and monitoring at each stage of the software development pipeline from development through production. Specific techniques mentioned include performing continuous security scanning, integrating security testing with other testing stages, automating security tasks using tools like Ansible, and sharing security data and lessons learned across teams to improve processes over time. The overall message is that security should be built into delivery rather than treated separately to avoid slowing software releases while still maintaining quality.
Orchestrating docker containers at scale (#DockerKRK edition)Maciej Lasyk
Slightly different version (original is here http://www.slideshare.net/d0cent/orchestrating-docker-containersatscale). This version was presented during first #Docker meetup in Kraków / Poland.
Orchestrating docker containers at scale (PJUG edition)Maciej Lasyk
Slightly changed version (original is here http://www.slideshare.net/d0cent/orchestrating-docker-containersatscale). This version was presented during Polish Java User Group meetup JavaCamp#13 in Kraków / Poland.
Orchestrating Docker containers at scaleMaciej Lasyk
Many of us already poked around Docker. Let's recap what we know and then think what do we know about scaling apps & whole environments which are Docker - based? Should we PaaS, IaaS or go with bare? Which tools to use on a given scale?
This document contains a list of various tools related to terminals, privacy, communication, productivity, and mobile topics. It discusses terminal emulators like guake and iterm2, VPN services like OpenVPN, messaging clients like IRC and XMPP, note taking apps like Evernote and Geeknote, and more. It concludes by inviting questions about any of the topics mentioned.
High Availability (HA) Explained - second editionMaciej Lasyk
I gave this talk at one of the biggest Linux conferences in Poland: 11 Liux Session that took place in Wrocław on 5/6-04-2014. It was a lightning talk covering subject of High Availability solutions, architecture, planning and deploying.
How could one create very sophisticated, open - source based monitoring solution that is very scalable and easy to deploy?
I gave this talk during on of the biggest Linux conferences in Poland: 11 Linux Session which took place in Wrocław on 5/6-04-2013
I gave this talk during first Infosec meetup in Kraków/Poland on 13th March 2014. After viewing this presentation you'll know how and why you should use SELinux (or others LSMs).
Is Red Hat / Fedora / Centos ready for lightweight Docker containers? Is Docker secure enough? How about SELinux? How could we deploy Jboss or Django within Docker / RHEL?
I gave this talk at DevOPS meetup in Krakow at 2014-02-26.
I gave this talk at Krakow/Poland DevOPS meetup. It was a lightning talk covering subject of High Availability solutions, architecture, planning and deploying.
4. Ansible & Rundeck?
→ monolityczne instalacje (np. CI)
→ a gdyby tak developerzy sami zarządzali CI?
→ i do tego są potrzebne narzędzia
→ ansible jest prosty
→ rundeck jest jeszcze prostszy
5. Ansible & Rundeck?
→ monolityczne instalacje (np. CI)
→ a gdyby tak developerzy sami zarządzali CI?
→ i do tego są potrzebne narzędzia
→ ansible jest prosty
→ rundeck jest jeszcze prostszy
6. Ansible & Rundeck?
→ monolityczne instalacje (np. CI)
→ a gdyby tak developerzy sami zarządzali CI?
→ i do tego są potrzebne narzędzia
→ ansible jest prosty
→ rundeck jest jeszcze prostszy
7. Ansible & Rundeck?
→ monolityczne instalacje (np. CI)
→ a gdyby tak developerzy sami zarządzali CI?
→ i do tego są potrzebne narzędzia
→ ansible jest prosty
→ rundeck jest jeszcze prostszy
8. Ansible & Rundeck?
→ monolityczne instalacje (np. CI)
→ a gdyby tak developerzy sami zarządzali CI?
→ i do tego są potrzebne narzędzia
→ ansible jest prosty
→ rundeck jest jeszcze prostszy
26. Czym jest Ansible?
→ prosty orkiestrator
→ tworzymy playbooki
→ posiada inventory hostów
→ używa ssh
→ pod spodem Python
→ przykładowy playbook I inventory
27. Czym jest Ansible?
→ prosty orkiestrator
→ tworzymy playbooki
→ posiada inventory hostów
→ używa ssh
→ pod spodem Python
→ przykładowy playbook I inventory
28. Czym jest Ansible?
→ prosty orkiestrator
→ tworzymy playbooki
→ posiada inventory hostów
→ używa ssh
→ pod spodem Python
→ przykładowy playbook I inventory
29. Czym jest Ansible?
→ prosty orkiestrator
→ tworzymy playbooki
→ posiada inventory hostów
→ używa ssh
→ pod spodem Python
→ przykładowy playbook I inventory
30. Czym jest Ansible?
→ prosty orkiestrator
→ tworzymy playbooki
→ posiada inventory hostów
→ używa ssh
→ pod spodem Python
→ przykładowy playbook I inventory
31. Czym jest Ansible?
→ prosty orkiestrator
→ tworzymy playbooki
→ posiada inventory hostów
→ używa ssh
→ pod spodem Python
→ przykładowy playbook I inventory
32. Czym jest Rundeck?
→ “Turn your operations procedures into self-service jobs.”
→ “Safely give others the control and visibility they need.”
→ "...it's the swiss army knife for ops."
→ biblioteka procedur
→ scheduler
→ łatwa integracja z systemami do incydentów
→ po CI / buildzie nadchodzi deployment
→ GUI & API
33. Czym jest Rundeck?
→ “Turn your operations procedures into self-service jobs.”
→ “Safely give others the control and visibility they need.”
→ "...it's the swiss army knife for ops."
→ biblioteka procedur
→ scheduler
→ łatwa integracja z systemami do incydentów
→ po CI / buildzie nadchodzi deployment
→ GUI & API
34. Czym jest Rundeck?
→ “Turn your operations procedures into self-service jobs.”
→ “Safely give others the control and visibility they need.”
→ "...it's the swiss army knife for ops."
→ biblioteka procedur
→ scheduler
→ łatwa integracja z systemami do incydentów
→ po CI / buildzie nadchodzi deployment
→ GUI & API
35. Czym jest Rundeck?
→ “Turn your operations procedures into self-service jobs.”
→ “Safely give others the control and visibility they need.”
→ "...it's the swiss army knife for ops."
→ biblioteka procedur
→ scheduler
→ łatwa integracja z systemami do incydentów
→ po CI / buildzie nadchodzi deployment
→ GUI & API
36. Czym jest Rundeck?
→ “Turn your operations procedures into self-service jobs.”
→ “Safely give others the control and visibility they need.”
→ "...it's the swiss army knife for ops."
→ biblioteka procedur
→ scheduler
→ łatwa integracja z systemami do incydentów
→ po CI / buildzie nadchodzi deployment
→ GUI & API
37. Czym jest Rundeck?
→ “Turn your operations procedures into self-service jobs.”
→ “Safely give others the control and visibility they need.”
→ "...it's the swiss army knife for ops."
→ biblioteka procedur
→ scheduler
→ łatwa integracja z systemami do incydentów
→ po CI / buildzie nadchodzi deployment
→ GUI & API
38. Czym jest Rundeck?
→ “Turn your operations procedures into self-service jobs.”
→ “Safely give others the control and visibility they need.”
→ "...it's the swiss army knife for ops."
→ biblioteka procedur
→ scheduler
→ łatwa integracja z systemami do incydentów
→ po CI / buildzie nadchodzi deployment
→ GUI & API
39. Czym jest Rundeck?
→ “Turn your operations procedures into self-service jobs.”
→ “Safely give others the control and visibility they need.”
→ "...it's the swiss army knife for ops."
→ biblioteka procedur
→ scheduler
→ łatwa integracja z systemami do incydentów
→ po CI / buildzie nadchodzi deployment
→ GUI & API
40. Czym jest Rundeck?
→ stworzony w Javie + Grails + Jetty + Bootstrap
→ początki w roku 2010
→ Apache license v2.0
→ Copyright 2010 DTO Solutions
→ “DevOps and Automation Specialists”
→ “RunDeck is a command dispatcher with a
modern web console. It lets you easily run commands
across a set of nodes.”
41. Czym jest Rundeck?
→ stworzony w Javie + Grails + Jetty + Bootstrap
→ początki w roku 2010
→ Apache license v2.0
→ Copyright 2010 DTO Solutions
→ “DevOps and Automation Specialists”
→ “RunDeck is a command dispatcher with a
modern web console. It lets you easily run commands
across a set of nodes.”
42. Czym jest Rundeck?
→ stworzony w Javie + Grails + Jetty + Bootstrap
→ początki w roku 2010
→ Apache license v2.0
→ Copyright 2010 DTO Solutions
→ “DevOps and Automation Specialists”
→ “RunDeck is a command dispatcher with a
modern web console. It lets you easily run commands
across a set of nodes.”
43. Czym jest Rundeck?
→ stworzony w Javie + Grails + Jetty + Bootstrap
→ początki w roku 2010
→ Apache license v2.0
→ Copyright 2010 DTO Solutions
→ “DevOps and Automation Specialists”
→ “RunDeck is a command dispatcher with a
modern web console. It lets you easily run commands
across a set of nodes.”
44. Czym jest Rundeck?
→ stworzony w Javie + Grails + Jetty + Bootstrap
→ początki w roku 2010
→ Apache license v2.0
→ Copyright 2010 DTO Solutions
→ “DevOps and Automation Specialists”
→ “RunDeck is a command dispatcher with a
modern web console. It lets you easily run commands
across a set of nodes.”
45. Czym jest Rundeck?
→ stworzony w Javie + Grails + Jetty + Bootstrap
→ początki w roku 2010
→ Apache license v2.0
→ Copyright 2010 DTO Solutions
→ “DevOps and Automation Specialists”
→ “RunDeck is a command dispatcher with a
modern web console. It lets you easily run commands
across a set of nodes.”
46. Główne koncepty Rundecka
→ projekt (kontener jobów, node'ów I konfiguracji)
→ job (sekwencja komend, skryptów)
→ workflow (sekwencja jobów)
→ nodes (hosty dostępne przez SSH)
→ wykonanie (uruchomienia jobów)
→ użytkownicy
→ uprawnienia
→ API
47. Główne koncepty Rundecka
→ projekt (kontener jobów, node'ów I konfiguracji)
→ job (sekwencja komend, skryptów)
→ workflow (sekwencja jobów)
→ nodes (hosty dostępne przez SSH)
→ wykonanie (uruchomienia jobów)
→ użytkownicy
→ uprawnienia
→ API
48. Główne koncepty Rundecka
→ projekt (kontener jobów, node'ów I konfiguracji)
→ job (sekwencja komend, skryptów)
→ workflow (sekwencja jobów)
→ nodes (hosty dostępne przez SSH)
→ wykonanie (uruchomienia jobów)
→ użytkownicy
→ uprawnienia
→ API
49. Główne koncepty Rundecka
→ projekt (kontener jobów, node'ów I konfiguracji)
→ job (sekwencja komend, skryptów)
→ workflow (sekwencja jobów)
→ nodes (hosty dostępne przez SSH)
→ wykonanie (uruchomienia jobów)
→ użytkownicy
→ uprawnienia
→ API
50. Główne koncepty Rundecka
→ projekt (kontener jobów, node'ów I konfiguracji)
→ job (sekwencja komend, skryptów)
→ workflow (sekwencja jobów)
→ nodes (hosty dostępne przez SSH)
→ wykonanie (uruchomienia jobów)
→ użytkownicy
→ uprawnienia
→ API
51. Główne koncepty Rundecka
→ projekt (kontener jobów, node'ów I konfiguracji)
→ job (sekwencja komend, skryptów)
→ workflow (sekwencja jobów)
→ nodes (hosty dostępne przez SSH)
→ wykonanie (uruchomienia jobów)
→ użytkownicy
→ uprawnienia
→ API
52. Główne koncepty Rundecka
→ projekt (kontener jobów, node'ów I konfiguracji)
→ job (sekwencja komend, skryptów)
→ workflow (sekwencja jobów)
→ nodes (hosty dostępne przez SSH)
→ wykonanie (uruchomienia jobów)
→ użytkownicy
→ uprawnienia
→ API
53. Główne koncepty Rundecka
→ projekt (kontener jobów, node'ów I konfiguracji)
→ job (sekwencja komend, skryptów)
→ workflow (sekwencja jobów)
→ nodes (hosty dostępne przez SSH)
→ wykonanie (uruchomienia jobów)
→ użytkownicy
→ uprawnienia
→ API
54. Wysokopoziomowe zalety Rundecka
→ Formalizacja procedur w spójnej formie
→ Przejrzysty dashboard
→ Logowanie, audyt, widoczność
→ Elastyczna granulacja uprawnień
→ Interfejs współpracy pomiędzy zespołami
55. Wysokopoziomowe zalety Rundecka
→ Formalizacja procedur w spójnej formie
→ Przejrzysty dashboard
→ Logowanie, audyt, widoczność
→ Elastyczna granulacja uprawnień
→ Interfejs współpracy pomiędzy zespołami
56. Wysokopoziomowe zalety Rundecka
→ Formalizacja procedur w spójnej formie
→ Przejrzysty dashboard
→ Logowanie, audyt, widoczność
→ Elastyczna granulacja uprawnień
→ Interfejs współpracy pomiędzy zespołami
57. Wysokopoziomowe zalety Rundecka
→ Formalizacja procedur w spójnej formie
→ Przejrzysty dashboard
→ Logowanie, audyt, widoczność
→ Elastyczna granulacja uprawnień
→ Interfejs współpracy pomiędzy zespołami
58. Wysokopoziomowe zalety Rundecka
→ Formalizacja procedur w spójnej formie
→ Przejrzysty dashboard
→ Logowanie, audyt, widoczność
→ Elastyczna granulacja uprawnień
→ Interfejs współpracy pomiędzy zespołami
68. → Jenkins is for Development (software builds)
→ Rundeck is for Operations (executing operational tasks)
→ Both are complementary
→ Rundeck has nodes (hosts) and inventory concept
→ Rundeck executes jobs / workflows on nodes (inventory)
→ Rundeck has ad-hoc commands (you can run those on nodes)
→ Rundeck provides you with fain – grained ACLs
Rundeck vs Jenkins?
69. → Jenkins is for Development (software builds)
→ Rundeck is for Operations (executing operational tasks)
→ Both are complementary
→ Rundeck has nodes (hosts) and inventory concept
→ Rundeck executes jobs / workflows on nodes (inventory)
→ Rundeck has ad-hoc commands (you can run those on nodes)
→ Rundeck provides you with fain – grained ACLs
Rundeck vs Jenkins?
70. → Jenkins is for Development (software builds)
→ Rundeck is for Operations (executing operational tasks)
→ Both are complementary
→ Rundeck has nodes (hosts) and inventory concept
→ Rundeck executes jobs / workflows on nodes (inventory)
→ Rundeck has ad-hoc commands (you can run those on nodes)
→ Rundeck provides you with fain – grained ACLs
Rundeck vs Jenkins?
71. → Jenkins is for Development (software builds)
→ Rundeck is for Operations (executing operational tasks)
→ Both are complementary
→ Rundeck has nodes (hosts) and inventory concept
→ Rundeck executes jobs / workflows on nodes (inventory)
→ Rundeck has ad-hoc commands (you can run those on nodes)
→ Rundeck provides you with fain – grained ACLs
Rundeck vs Jenkins?
72. → Jenkins is for Development (software builds)
→ Rundeck is for Operations (executing operational tasks)
→ Both are complementary
→ Rundeck has nodes (hosts) and inventory concept
→ Rundeck executes jobs / workflows on nodes (inventory)
→ Rundeck has ad-hoc commands (you can run those on nodes)
→ Rundeck provides you with fain – grained ACLs
Rundeck vs Jenkins?
73. → Jenkins is for Development (software builds)
→ Rundeck is for Operations (executing operational tasks)
→ Both are complementary
→ Rundeck has nodes (hosts) and inventory concept
→ Rundeck executes jobs / workflows on nodes (inventory)
→ Rundeck has ad-hoc commands (you can run those on nodes)
→ Rundeck provides you with fain – grained ACLs
Rundeck vs Jenkins?
74. Rundeck vs Jenkins?
→ Jenkins is for Development (software builds)
→ Rundeck is for Operations (executing operational tasks)
→ Both are complementary
→ Rundeck has nodes (hosts) and inventory concept
→ Rundeck executes jobs / workflows on nodes (inventory)
→ Rundeck has ad-hoc commands (you can run those on nodes)
→ Rundeck provides you with fain – grained ACLs
88. Rundeck & Ansible
→ Use Rundeck only as GUI, API and scheduler
→ Bring Rundeck inventory to common with Ansible
→ Remember that Rundeck is stupid
→ Create workspace for jobs
→ Clean up this workspace automatically
→ Only run ansible-playbooks
→ Good practices (in my opinion)?
→ Common provisioning core jobs
→ Common “playbook-runner” job
→ Integrate Rundeck & Ansible debug
89. Rundeck & Ansible
→ Use Rundeck only as GUI, API and scheduler
→ Bring Rundeck inventory to common with Ansible
→ Remember that Rundeck is stupid
→ Create workspace for jobs
→ Clean up this workspace automatically
→ Only run ansible-playbooks
→ Good practices (in my opinion)?
→ Common provisioning core jobs
→ Common “playbook-runner” job
→ Integrate Rundeck & Ansible debug
90. Rundeck & Ansible
→ Use Rundeck only as GUI, API and scheduler
→ Bring Rundeck inventory to common with Ansible
→ Remember that Rundeck is stupid
→ Create workspace for jobs
→ Clean up this workspace automatically
→ Only run ansible-playbooks
→ Good practices (in my opinion)?
→ Common provisioning core jobs
→ Common “playbook-runner” job
→ Integrate Rundeck & Ansible debug
91. Rundeck & Ansible
→ Use Rundeck only as GUI, API and scheduler
→ Bring Rundeck inventory to common with Ansible
→ Remember that Rundeck is stupid
→ Create workspace for jobs
→ Clean up this workspace automatically
→ Only run ansible-playbooks
→ Good practices (in my opinion)?
→ Common provisioning core jobs
→ Common “playbook-runner” job
→ Integrate Rundeck & Ansible debug
92. Rundeck & Ansible
→ Use Rundeck only as GUI, API and scheduler
→ Bring Rundeck inventory to common with Ansible
→ Remember that Rundeck is stupid
→ Create workspace for jobs
→ Clean up this workspace automatically
→ Only run ansible-playbooks
→ Good practices (in my opinion)?
→ Common provisioning core jobs
→ Common “playbook-runner” job
→ Integrate Rundeck & Ansible debug
93. Rundeck & Ansible
→ Use Rundeck only as GUI, API and scheduler
→ Bring Rundeck inventory to common with Ansible
→ Remember that Rundeck is stupid
→ Create workspace for jobs
→ Clean up this workspace automatically
→ Only run ansible-playbooks
→ Good practices (in my opinion)?
→ Common provisioning core jobs
→ Common “playbook-runner” job
→ Integrate Rundeck & Ansible debug
94. Rundeck & Ansible
→ Use Rundeck only as GUI, API and scheduler
→ Bring Rundeck inventory to common with Ansible
→ Remember that Rundeck is stupid
→ Create workspace for jobs
→ Clean up this workspace automatically
→ Only run ansible-playbooks
→ Good practices (in my opinion)?
→ Common provisioning core jobs
→ Common “playbook-runner” job
→ Integrate Rundeck & Ansible debug
95. Rundeck & Ansible
→ Use Rundeck only as GUI, API and scheduler
→ Bring Rundeck inventory to common with Ansible
→ Remember that Rundeck is stupid
→ Create workspace for jobs
→ Clean up this workspace automatically
→ Only run ansible-playbooks
→ Good practices (in my opinion)?
→ Common provisioning core jobs
→ Common “playbook-runner” job
→ Integrate Rundeck & Ansible debug
96. Rundeck & Ansible
→ Use Rundeck only as GUI, API and scheduler
→ Bring Rundeck inventory to common with Ansible
→ Remember that Rundeck is stupid
→ Create workspace for jobs
→ Clean up this workspace automatically
→ Only run ansible-playbooks
→ Good practices (in my opinion)?
→ Common provisioning core jobs
→ Common “playbook-runner” job
→ Integrate Rundeck & Ansible debug
97. Rundeck & Ansible
→ Use Rundeck only as GUI, API and scheduler
→ Bring Rundeck inventory to common with Ansible
→ Remember that Rundeck is stupid
→ Create workspace for jobs
→ Clean up this workspace automatically
→ Only run ansible-playbooks
→ Good practices (in my opinion)?
→ Common provisioning core jobs
→ Common “playbook-runner” job
→ Integrate Rundeck & Ansible debug
98. Rundeck & Ansible
run job on localhost node
this job actually invokes ansible-playbook
on choosen hosts
100. Rundeck & Ansible plugin
I'm new to both Rundeck and Ansible so I expect
there to be room for improvements.
Only basic features have been implemented
in this first pass, so I can play around with both tools.
Liking it very much so far! :)
https://github.com/Batix/rundeck-ansible-plugin
101. Rundeck API
→ nieoficjalny wrapper pythonowy:
https://github.com/marklap/rundeckrun
→ rundeck_api_helper.py
→ apitoken.policy vs JSESSIONID
102. Rundeck API
→ nieoficjalny wrapper pythonowy:
https://github.com/marklap/rundeckrun
→ rundeck_api_helper.py
→ apitoken.policy vs JSESSIONID
103. Rundeck API
→ nieoficjalny wrapper pythonowy:
https://github.com/marklap/rundeckrun
→ rundeck_api_helper.py
→ apitoken.policy vs JSESSIONID
104. To jak z tą współpracą DEV ↔ OPS?
(aka Ocado – use case)
105. To jak z tą współpracą DEV ↔ OPS?
(aka Ocado – use case)
106. To jak z tą współpracą DEV ↔ OPS?
(aka Ocado – use case)
107. To jak z tą współpracą DEV ↔ OPS?
(aka Ocado – use case)
108. To jak z tą współpracą DEV ↔ OPS?
(aka Ocado – use case)
109. To jak z tą współpracą DEV ↔ OPS?
(aka Ocado – use case)
110. To jak z tą współpracą DEV ↔ OPS?
(aka Ocado – use case)
111. To jak z tą współpracą DEV ↔ OPS?
(aka Ocado – use case)
112. To jak z tą współpracą DEV ↔ OPS?
(aka Ocado – use case)
113. To jak z tą współpracą DEV ↔ OPS?
(aka Ocado – use case)
114. To jak z tą współpracą DEV ↔ OPS?
(aka Ocado – use case)
115. To jak z tą współpracą DEV ↔ OPS?
(aka Ocado – use case)
provisioning jobs, rundeck maintenance
116. To jak z tą współpracą DEV ↔ OPS?
(aka Ocado – use case)
provisioning jobs, rundeck maintenance
maintenance of own app clusters
creating app clusters
costs supervision
117. To jak z tą współpracą DEV ↔ OPS?
Dobre praktyki utrzymania Rundecka w środowisku dev – ops?
→ **nie** edytujcie jobów na codzień w UI
→ joby definiujcie w repo i importujcie (np. przez wrapper API)
→ dzielcie się między sobą swoimi jobami / template'ami
→ trzymajcie logikę w Ansible'u (Puppecie / cokolwiek) – nie
w definicjach jobów rundeckowych
→ testujcie automatycznie wykonanie swoich jobów
→ przekręcajcie często całą instancję Rundecka (powtarzalność)
118. To jak z tą współpracą DEV ↔ OPS?
Dobre praktyki utrzymania Rundecka w środowisku dev – ops?
→ **nie** edytujcie jobów na codzień w UI
→ joby definiujcie w repo i importujcie (np. przez wrapper API)
→ dzielcie się między sobą swoimi jobami / template'ami
→ trzymajcie logikę w Ansible'u (Puppecie / cokolwiek) – nie
w definicjach jobów rundeckowych
→ testujcie automatycznie wykonanie swoich jobów
→ przekręcajcie często całą instancję Rundecka (powtarzalność)
119. To jak z tą współpracą DEV ↔ OPS?
Dobre praktyki utrzymania Rundecka w środowisku dev – ops?
→ **nie** edytujcie jobów na codzień w UI
→ joby definiujcie w repo i importujcie (np. przez wrapper API)
→ dzielcie się między sobą swoimi jobami / template'ami
→ trzymajcie logikę w Ansible'u (Puppecie / cokolwiek) – nie
w definicjach jobów rundeckowych
→ testujcie automatycznie wykonanie swoich jobów
→ przekręcajcie często całą instancję Rundecka (powtarzalność)
120. To jak z tą współpracą DEV ↔ OPS?
Dobre praktyki utrzymania Rundecka w środowisku dev – ops?
→ **nie** edytujcie jobów na codzień w UI
→ joby definiujcie w repo i importujcie (np. przez wrapper API)
→ dzielcie się między sobą swoimi jobami / template'ami
→ trzymajcie logikę w Ansible'u (Puppecie / cokolwiek) – nie
w definicjach jobów rundeckowych
→ testujcie automatycznie wykonanie swoich jobów
→ przekręcajcie często całą instancję Rundecka (powtarzalność)
121. To jak z tą współpracą DEV ↔ OPS?
Dobre praktyki utrzymania Rundecka w środowisku dev – ops?
→ **nie** edytujcie jobów na codzień w UI
→ joby definiujcie w repo i importujcie (np. przez wrapper API)
→ dzielcie się między sobą swoimi jobami / template'ami
→ trzymajcie logikę w Ansible'u (Puppecie / cokolwiek) – nie
w definicjach jobów rundeckowych
→ testujcie automatycznie wykonanie swoich jobów
→ przekręcajcie często całą instancję Rundecka (powtarzalność)
122. To jak z tą współpracą DEV ↔ OPS?
Dobre praktyki utrzymania Rundecka w środowisku dev – ops?
→ **nie** edytujcie jobów na codzień w UI
→ joby definiujcie w repo i importujcie (np. przez wrapper API)
→ dzielcie się między sobą swoimi jobami / template'ami
→ trzymajcie logikę w Ansible'u (Puppecie / cokolwiek) – nie
w definicjach jobów rundeckowych
→ testujcie automatycznie wykonanie swoich jobów
→ przekręcajcie często całą instancję Rundecka (powtarzalność)
123. To jak z tą współpracą DEV ↔ OPS?
Rundeck per zespół? Czemu nie
124. To jak z tą współpracą DEV ↔ OPS?
Rundeck per zespół? Czemu nie
125. To jak z tą współpracą DEV ↔ OPS?
Rundeck per zespół? Czemu nie