Etikettarkiv: mongodb

DevOps Säkerhet

DevOps, , , , , , , , , , , , , , ,

Att jobba med DevOps samt IT-säkerhet är några av de områden som jag gillar mest. Därför är det intressant att ibland stanna upp och reflektera. För inom DevOps handlar det oftast om att skeppa kod så snabbt som möjligt och bygga skalbara och snabba mikroinfrastrukturer med continuous integration. Säkerhet däremot ses ofta som en bromskloss i utvecklingsarbetet.

Det går att fuska med säkerhet: Genomföra saker snabbt men se säkerheten som ett lån med ränta. Att betala tillbaka på lånet snabbare gör att säkerheten blir bättre och det blir inte lika dyrt längre fram (technical debt).

Att ta med säkerheten tidigt i sin planering är viktigt, för använder ni Docker så se till att använda SELinux eller AppArmor (vilket bl.a. Ubuntu Snappy gör som standard).

Exponera ej Elasticsearch, Redis, MongoDB eller andra databaser direkt mot Internet, vilket tyvärr förekommer och nyttjas av elakingar.

Se även till att inte lagra lösenord i klartext och genomför säker radering av information. Visste du exempelvis att Mac OS X har kommandot srm?

srm – securely remove files or directories

Nu är det nog med rant för det blir faktiskt bättre. Och för att ge lite matnyttiga tips tänk på följande:

10 tips till säkrare DevOps

  1. Genomför inte bara backup. Kontrollera även löpande att den verkligen innehåller allt och fungerar. Backup för prod ska ej vara tillgänglig från stage och vice versa.
  2. Prod-, stage- och utvecklingsmiljöer ska ej dela nycklar, lösenord etc.
  3. Tänk på att ej lägga alla ägg i samma korg. Nyttja exempelvis Amazons availability zones.
  4. Kryptera så mycket som möjligt. Inte bara in-transit utan även lokalt, undvik helt klartextprotokoll samt införskaffa SSL-Certifikat.
  5. ossecLogga mycket och filtrera samt arkivera med hjälpmedel såsom OSSEC. Som förresten även kan hålla koll på filintegritet.
  6. Bevaka med verktyg såsom Nagios, Pingdom och New Relic. Glöm inte ändpunkter för API (10 saker som Bit.ly glömde att bevaka).
  7. Genomför löpande säkerhetskontroller med verktyg såsom Qualys, Nessus och Detectity. Även manuella återkommande granskningar är att rekommendera av företag som utför penetrationstester.
  8. Omvärldsbevaka och håll Er uppdaterad när det kommer nya sårbarheter i de mjukvaror som Er infrastruktur använder. Vad är best practices just nu för att lagra lösenord, är det bcrypt, scrypt eller pbkdf2?
  9. Segmentera och filtrera så mycket som möjligt. Ingen enskild server eller konto ska ha tillgång till allt.
  10. Checka aldrig in lösenord, nycklar eller annat känsligt till ett repo.

Tänk inte bara DevOps, tänk även SecOps.

Lös inte nästa problem som du stöter på, på följande sätt (saxat från Stackoverflow)

https stackoverflow

NoSQL: Redis, CouchDB och MongoDB prestanda

Ingen kategori, , , , ,

Eftersom jag testar NoSQL-mjukvaror såom Redis, CouchDB och MongoDB just nu  så genomförde jag ett litet prestandatest där Redis vann över CouchDB och MongoDB.

Så här lång tid tog det att stoppa in 100 000 objekt i en databas:

MongoDB

db version v1.2.2, pdfile version 4.5
real    13.306s
user    9.130s
sys     0.940s

Redis

Redis version 1.3.17
real    7.044s
user    5.330s
sys     0.070s
Redis version 2.1.5 (8d3e063a:0)
real    6.400s
user    4.760s
sys     0.110s

CouchDB

Apache CouchDB version 0.10.0

Fick inte vara med för att det tog 4 sekunder att sätta in 100 objekt. Ungefär samma prestanda som Amazon SQS, och då använde jag även full_commit=False vilket bör öka prestandan. Ska testa Hovercraft för att se om jag kan få upp prestandan.

Observera även att ovan tid inkluderar exekvering av Python, inladdning av moduler samt den kod som körs mellan det att information trycks in.

MongoDB – Test av NoSQL, del 1

Ingen kategori, , , , , , ,

Som läsare av denna blogg så vet du nog vid det här laget att jag har en stor kärlek till det som kallas för NoSQL. Dvs systemlösningar som inte enbart innefattar SQL.

Tre av de stora kandidaterna till att snabba upp MySQL eller byta ut MySQL helt heter Redis, CouchDB samt MongoDB men vilken ska man välja? Som du kanske förstår så finns det inget bra svar på detta men jag tänkte här nedan försöka ge en liten inblick hur det är att installera och använda respektive dokumentcentrerad (icke SQL) databas.

Andra NoSQL-system som är värda att nämna är Neo4j, Tokyo Cabinet, Memcache samt Cassandra.

Bakgrund MongoDB

Används av sajter såsom bit.ly och foursquare. Utvecklat i C++ och överbryggar RDBMS och nyckel-värde lagring.

Installation MongoDB

Installationen gick mycket smidigt på mitt Ubuntu 10.10 system med hjälp av apt:

$ sudo apt-get install mongodb-server

Då installeras MongoDB, xulrunner samt så läggs en användare vid namn mongodb upp. Mongodb lyssnar även på två TCP-portar på 127.0.0.1

För PHP-stöd till MongoDB så kan pecl-porten användas och installeras på följande sätt:

$ sudo pecl install mongo

Om du får ett felmeddelande i stil med:

sh: phpize: not found
ERROR: `phpize’ failed

Så måste Ubuntu-paketet php5-dev installeras där phpize ingår. För att sedan få php att ladda in mongo-modulen så kan följande kommando användas:

$ sudo sh -c ”echo extension=mongo.so > /etc/php5/conf.d/mongo.ini”

För att sedan använda MongDB så kan exempelvis följande PHP-kod användas för test:


<?php

// connect

$m = new Mongo();

// select a database

$db = $m->comedy;

$collection = $db->cartoons;

// add an element

$obj = array( "title" => "Calvin and Hobbes", "author" => "Bill Watterson" );

$collection->insert($obj);

// find everything in the collection

$cursor = $collection->find();

// iterate through the results

foreach ($cursor as $obj) {

echo $obj["title"] . "\n";

}

// disconnect

$m->close();

?>

För att sedan verifiera testa:

$ php mongodb.php

Så bör följande visas:
Calvin and Hobbes
Andra inlägg i denna serie kommer snart.