Post-mortem yapma yeteneğini kaybetmeden değişmez sunucu kalıbı nasıl uygulanır?


12

Değiştirilemeyen sunucu düzeni, dağıtımların tekrarlanabilirliğini destekleyen bir dağıtım disiplinidir. “ Bir zamanlar konuşlandırılan, hiçbir zaman değiştirilmeyen, yalnızca yeni bir güncellenmiş örnekle değiştirilen bir sunucunun ” ve bu disiplini uygulamak için sunucu dağıtımının otomasyonunu gerektirmesi ile karakterizedir. Bu otomasyonun sayısız operasyonel avantajı vardır, en önemlilerinden biri bir altyapıdaki başarısız örneklerin hızlı ve güvenilir bir şekilde değiştirilmesine izin vermektir. Bu otomasyon aynı zamanda sunucu dağıtımının sürümlü yazılım eserleri tarafından tanımlandığını ve yinelemeli iyileştirmelere tabi olduğunu ima eder.

Bu disiplinin uygulamalarının popüler bir yönü, uzaktan erişim yöntemlerinin başlatıldıktan sonra sunucuya kaldırılmasıdır (özellikle SSH erişiminin kaldırılması). Uzaktan erişimi kaldırmak, sunucunun yapılandırmasının dağıtım otomasyonu tarafından hazırlanan yapılandırmayla eşleşmesini sağlamanın kolay bir yoludur.

Bununla birlikte, bir yazılım hatası nedenini araştırırken, yapılandırılmış izlemeye güvenmek her zaman yeterli değildir ve makineye uzaktan erişim gerekebilir. Sunucu izlemenin tüm hata kaynaklarını kapsamaması veya izlemenin sunucu arızasının kendisi tarafından bozulabilmesi yaygın bir durumdur, bu da sunucunun belleği tükenirse veya işlem sınırına ulaşırsa büyük olasılıkla olur.

Post-mortem yapma yeteneğini kaybetmeden değişmez sunucu kalıbı nasıl uygulanır?

Yanıtlar:


9

Her şeyden önce, değişmez bir sunucuda ssh'ın kaldırılması hiçbir değişiklik olmayacağını garanti etmez, dahası, bir uzaktan erişim kanalını kaldırarak saldırı yüzeyini azalttığınız bir şeyi değiştirmenize gerek olmadığı için.

Bir çeşit post-mortem tutmanın bir yolu da günlük merkezileştirmedir. Bunu başarmak için sayısız yöntem var, ELK yığını, Splunk, syslog ...

Değişmez bir sunucu için bir post mortem tutmanın bir başka daha kaba yolu, programın çekirdek dökümü toplamak için kapatma işleminde bir komut dosyası bulundurmaktır (değişmez bir sunucu başarısız olur ve yerine yeni bir tane döndürür). bellek dökümü ve günlüklerin çoğu ile birlikte analiz için uzak bir sisteme gönderin.

Bu çözümün ana avantajı, sorunlu zamanda yalnızca başarısız olan sistem bilgilerini geri almanız ve periyodik olarak almaktan daha büyük bilgiler toplamanıza izin vermesidir.

Bunu nasıl başaracağınız konusunda daha spesifik olmak zor, her dağıtımın bir şeyleri almanın bir yolu var ve genel bir örneğim yok.


7

SSH erişiminizin olmaması, makineye erişmenin bir yolu olmadığı anlamına gelmez. Büyük olasılıkla, aşağıdakileri de yapabileceğiniz bazı bulut operatörlerinde çalıştıracaksınız:

  • makinenin anlık görüntüsünü alın. Kutuyu yok etmeden önce, daha sonra analiz etmek için bir anlık görüntü alabilirsiniz.
  • makineye konsoldan erişin. Muhtemelen bunun için root şifresine sahip olmanız gerekir, ancak bazı bulut sağlayıcıları istedikleri zaman konsol erişimi için rastgele bir root şifresi enjekte edebilir.

Bunlar esas olarak makinenize "fiziksel" erişimdir ve diğer erişim türlerini kaldırsanız bile kullanılabilir. Bu arayüzleri de sınırlandırabilirsiniz.

Bunun dışında @Tensibai daha iyi bir şey yapmak için uygun kayıt ve izleme kurmak olduğunu söyledi, bu yüzden bir post mortem yapmak zorunda kalacak zaman, bunu yapmak için yeterli veri var.


4
Konsol erişimine karşı koymak için AWS EC2 herhangi bir konsol erişimi sağlamaz, SSH'yi yapılandırmazsanız, makineye erişiminiz olmaz. Makine biriminin anlık görüntüsünü almak, verileri analiz etmek için "adli" bir örneğe yeni bir disk olarak monte etmek yardımcı olabilir.
Tensibai
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.