Geplaatst op

Wethinkonline at DevOpsDays 2020 Madrid

Key takeaways from the Madrid DevOps conference. That is where the K8s all gathered around their pods with a Helm. If you are a cloud native speaker, these things should be crystal clear.


Perspective: moving from a classic VM oriented architecture to container based app runtime infrastructure.


Complicated decisions on cloud native resources.

  • Need for a lot of diff tooling for networking, load balancing, monitoring… fragmented Kubernetes landscape still a challenge. Hence importance abstraction via cloud services hiding kubernetes platform complexity.
    https://www.influxdata.com/blog/will-kubernetes-collapse-under-the-weight-of-its-complexity/
  • When you try to run your own kubernetes cluster in production, innocent kitties will die 😉
  • choose the right cloud provider, MS Azure, IBM, Google Cloud, Oracle (avoid vendor lockin?)
    > Hybrid solution?
    Overcome Vendor Lock-In by Integrating Already Available Container Technologies ( Towards Transferability in Cloud Computing for SMEs)
  • Move from classic devops to container based devops; Requires careful restructuring of teams and extra cognitive load for devs. 
    • Very close Dev-Ops communication, has advantage of immediate feedback loop when deploying changes to prod.
    • Still importance for a dedicated Ops role for Monitoring, CI/CD tooling, QA… Having one team that handles all is not an optimal strategy in this sense.

      DevOps Anti-Type B - The DevOps Silo
      Source: Team topologies
    • Organizations … understand the link between organizational structure and the software they create. For example, Netflix and Amazon structure themselves around multiple small teams, each one autonomous over a small part of the system.

Perspective: CI tools SaaS vs on premise tools

  • TCO on premise CI is high:on premise ci hosting eg. Jenkins may have a low initial cost but maintenance hours add up quickly over time (broken plugins, cost of jenkins server itself etc)
  • See slides on top of article with comparison charts of features.

https://medium.com/@rothgar/why-kubernetes-is-abbreviated-k8s-905289405a3c

! Hasta luego Madrid ✌️

Geplaatst op

Drupal 8 updaten zonder composer

In Drupal 7 moesten modules die afhankelijk zijn van externe PHP bibliotheken handmatig worden geüpdatet , door de bibliotheken in de module map zelf te plaatsen (bv. een libraries submap). Of alternatief door gebruik te maken van de libraries API om zo via de folders sites/all/libraries en sites/sitename/libraries libraries te laden.

Sinds Drupal 8 zijn deze taken sterk geautomatiseerd voor complexe sites, de geprefereerde updatemethode is nu Composer. Voor Drupal-websites die afhankelijk zijn van veel contrib modules en hun afhankelijkheidsstructuren is dit uitstekend.

Composer lost het dependency management vraagstuk op door de bibliotheken centraal in de vendor folder te updaten. Dit betekent ook dat je de composer methode moet gebruiken om de site bij te werken, als jouw website library-dependent modules gebruikt.

Redenen om geen composer te gebruiken in combinatie met Drupal 8

Als je een eenvoudige site setup hebt (een website zonder modules die afhankelijk zijn van externe libraries) kan het zijn dat je geen Composer wenst te gebruiken. Composer vereist een site beheerder kennis te hebben van een ontwikkeltool, het stelt hoge geheugenvereisten en open firewall access voor verschillende bronnen…. 1 2 3

In dit geval kan je doorgaan met het updaten via de oude methode. Dat wil zeggen, het downloaden van de laatste Drupal release, het opruimen/overschrijven van de bestanden in de vendor map, hetzij via drush, of het verkrijgen van de Drupal release tarball.

Automatiseren van Drupal 8 updates

Voor Drupal 8 hebben wij op Github volgende tool gereleased:

https://github.com/wethinkonline/auto-update-drupal

Naast het updaten zonder composer zorgt de auto update tool voor:

  • het behoud van .htaccess toevoegingen na updates
  • het nemen van backups van de website en databank
  • het automatiseren van updates door het script in jouw crontab te plaatsen

Waarom moet je composer of Ludwig gebruiken als je externe bibliotheken voor modules nodig hebt?

Door de manier waarop Composer werkt, kunnen deze bibliotheken niet handmatig worden geüpload naar de map met libraries van de website.

In plaats daarvan moet Composer worden gebruikt om de module te downloaden, die vervolgens de vereiste bibliotheken ophaalt. Zodra Composer wordt gebruikt om een enkele module te beheren, moet het ook worden gebruikt om Drupal core te beheren en bij te werken. Dit is zo omdat handmatige Drupal core updates de vendor map vervangen en de gedownloade bibliotheken verwijderen. quote Ludwig-project