Zobrazují se příspěvky se štítkemdatacentrum. Zobrazit všechny příspěvky
Zobrazují se příspěvky se štítkemdatacentrum. Zobrazit všechny příspěvky

2019-03-08

Používání SonarQube pro DevOps

Zprovozňoval jsem analytický nástroj SonarQube pro použití v Jenkins pipeline, nicméně jako standalone instanci tedy bez pluginu. K použití GetCodeflow s jehož autorem se znám jsem nedosal povolení od správce repozitáře, je potřeba tedy udělat analytiku lokálně. Kdybych náhodou instaloval nový server, píšu si následující poznámky.


Stažený instalátor SonarQube není instalátor. Složku je potřeba rozumně pojmenovat a někam permanentně umístit jako třeba C:\Program Files\sonarqube

Nejprve je nutné nainstalovat 64 bitovou Javu (JRE) a složku propojit s konfiguračním souborem C:\Program Files\sonarqube\conf\wrapper.conf, kam je třeba vložit řádek 
wrapper.java.command=C:\Program Files\Java\jre1.8.0_202\bin\java
Dále můžete vyzkoušet spuštění StartSonar.bat ze složky bin/windows-x86-64 přes command line (uvidíte případné chyby), pokud se načítá aplikace http://localhost:9000 (login admin/admin) je vše v pořádku. Kdyby byl větší problém, otevřete C:\Program Files\sonarqube\logs\sonar.log a koukněte na konec souboru co bylo příčinou pádu.
wrapper  | Waiting to start...
wrapper  | The SonarQube service was launched, but failed to start.
Před plným používáním je třeba doladit několik detailů. Zejména instalace samospouštěcí služby. Otevřete příkazový řádek v admin režimu, nalistujte C:\Program Files\sonarqube\bin\windows-x86-64\ a spusťte InstallNTService.bat, poté by se měla v systémových službách (services.msc) objevit služba SonarQube s automatickým startem.

V průběhu prvního testovacího buildu jsem se vinou obrovského solution (3 miliony řádku kódu ve 4,5 GB zdrojových kódů) potýkal s nedostatkem paměti, kterou bylo potřeba rozšířit. 32 bitová aplikace zvládá alokovat maximálně 2 GB paměti, proto je potřeba používat 64 bitovou. 
INFO: EXECUTION FAILURE
INFO: Final Memory: 15M/247M
ERROR: Error during SonarQube Scanner execution
ERROR: Java heap space
ERROR: The SonarQube Scanner did not complete successfully. Post-processing failed. Exit code: 1 
Nastavení se provádí v C:\Program Files\sonarqube\conf\sonar.properities. Hodnota sonar.web.javaOpts=-Xmx<číslo>m uvádí maximální možnou paměť a -Xms<číslo>m hodnotu při startu, rozpětí je tedy žádoucí velké.

Funkční nastavení: wrapper.conf
wrapper.java.additional.1=-Xms2048m
wrapper.java.additional.1=-Xmx%WRAPPER_SYSMEM_80.0%
Funkční nastavení: sonar.properties
sonar.web.javaOpts=-Xmx512m -Xms128m -XX:+HeapDumpOnOutOfMemoryError
sonar.ce.javaOpts=-Xmx8192m -Xms1024m -XX:+HeapDumpOnOutOfMemoryError
Jak vystavit SonarQube do sítě? Na mém serveru běží také IIS, takže je potřeba rezervovat adresu v IIS a nastavit redirect podle návodu. Pro samotné přepnutí aplikace pak stačilo nastavit DNS záznamy a uvnitř v aplikaci položku sonar.core.serverBaseURL => Administration/Server base URL. Navíc je potřeba zvýšit limit pro uploadované soubory, jinak končí analýza chybou "ERROR: Failed to upload report - HTTP code 404: "

Jak mít permamentní výsledky v databázi? Je potřeba C:\Program Files\sonarqube\conf\sonar.properities propojit s DB serverem a to následujícím způsobem. V DB (MSSQL) vytvořit databázi (v options zvolit Collation = Latin1_General_CS_AS), vytvořit uživatele a přiřadit mu db_owner právo. (ideální je zkusit se připojit přes Microsoft SQL Server Management Studio). A vlastní konfigurace tedy
sonar.jdbc.username=sonarqube
sonar.jdbc.password=password

sonar.jdbc.url=jdbc:sqlserver://<IPorDNS>:1433;databaseName=sonarqube
A to je vše, restartovat službu SonarQube a nechat nástroj znovu načíst. Případné chyby jsou ve web.log.

Jak propojit přihlášení do rozhraní SonarQube přes Active Directory? Předně je třeba vytvořit uživatele (?) ve zmíněné doméně, který bude sloužit pro přístup samotného SonarQube. Konfigurace v sonar.properities je pak následující
sonar.security.realm=LDAP
sonar.security.savePassword=true
#sonar.security.localUsers=admin
ldap.url=ldap://DOMAIN.local:389
ldap.bindDn=sonarqube@DOMAIN.local
ldap.bindPassword=PASSinPLAINTEXT
#ldap.bindPassword={aes}passhashed
ldap.user.baseDn=cn=users,dc=DOMAIN,dc=local
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
ldap.group.baseDn=DC=inpulsetest,DC=local
ldap.group.request=(&(objectClass=group)(memberUid={uid}))
Není potřeba dalšího pluginu a přihlašování pak probíhá jen zadáním username bez domény. Pokud chcete mít z uživatelů administrátory, jde to snadno přes položku Administration/Security/Global permission a zaškrtnout příslušná oprávnění v sonar-users skupině.
 
Každopádně po této konfiguraci funguje nástroj v enterprise režimu a podporuje DevOps proces.

2018-11-23

Nastavení spouštění Jenkins úlohy na webhook z Gitu

Hrál jsem si s nastavováním automatického spouštění úlohy v Jenkins po commitu do GitHubu. Čistě teoreticky jde o triviální věc, kterou popisuje spousta videí, nicméně v praxi jsem narazil na několik problémů, které si tady odložím, abych to příště nemusel řešit. Třeba to pomůže i někomu dalšímu.

Na začátek hezké video, které popisuje úlohu bez nastavení tajného hesla:

Nejprve je třeba připravit Jenkins, předpokládám, že už vám joby a integrace s GitHubem funguje, jen pro informaci je třeba mít nainstalovaný plugin GitHubu.

Dále musí být dostupná adresa JENKINS_URL/github-webhook/ z veřejného internetu (nebo filtru podle GitHub IP adres), případně přenastavena na jinou v JENKINS_URL/configure sekce GitHub/Advanced (to druhé advanced) a políčko "Override Hook URL/Specify another hook URL for GitHub configuration" 

Manage webhooks zůstane nezaškrtnuto (sekce A.3) pro manuální instalaci webhooku na GitHubu.

Protože nechceme, aby každý, kdo se dostane k odkazu webhooku, spouštěl úlohu, je třeba nastavit heslo neboli "shared secret", respektive jej vytvořit v JENKINS_URL/credentials/add/secret text/system/ a pak nalinkovat "Shared secret". Nicméně je taky fajn to nejdříve vyzkoušet, že to funguje a secret přidat později (nezapomněout na to!).

Poté je třeba registrovat job, který se na webhook spustí. Zpátky na seznam úloh, rozklinout ho a možnost configure, pak checkbox GitHub project a do Project url vložit https://github.com/<user>/<repository>/ toto musí být uděláno manuálně.
Níže pak ještě zaškrtnout "GitHub hook trigger for GITScm polling", nebo to přidat do pipeline definice úlohy jako triggers{githubPush()}.

Poslední částí je nastavit URL webook na GitHubu, link: https://github.com/<user>/<repository>/settings/hooks/new, kde se vloží Payload URL: JENKINS_URL/github-webhook/ včetně lomítka na konci, content type jako application/json a secret je ten námi zvolený a uložený string.

Poté je výhodné udělat testovací ping a počkat na zelenou fajku, nicméně vlastní run jobu začně až po prvním commitu. Zejména na začátku nespěchtejte, občas to chce čas na reakci.


2018-11-19

Namespace Microsoft.SqlServer (are you missing an assembly reference?)

Chvíli jsem bojoval s chybovou hlášku u SW buildu na novém serveru, která se při sestavování stejného řešení na starším serveru neprojevovala, což bylo zjevně podezřelé. 


Její znění:
error CS0234: The type or namespace name 'Management' does not exist in the 
namespace 'Microsoft.SqlServer' (are you missing an assembly reference?) 
[...Installer.csproj]
Nepomohlo ruční doinstalování přes Nuget, ani doinstalování Microsoft SQL Server Feature Packu, ale bylo potřeba přidat celý SQL Server 2017 Developer edition, který zjevně deplnil některou závislost do systému Windows Server.

Ještě zkusím i odinstalování...
 

2018-10-24

Jenkins stops pipeline from Powershell

When you realize inside some job that you want to terminate running job in Jenkins you need to find way, hot to pass message to proper level where is Jenkins actually able to terminate the job. I am using this way with calling authorized URL which is terminating the job.

Jenkinsfile pipline is calling powershell and passing there API token from credentials (manually inserted to Jenkins => Credentials)
script
{
    if(env.GIT_PREVIOUS_SUCCESSFUL_COMMIT !=  null)
    {
        withCredentials([string(credentialsId: 'JenkinsAPIcredentials', variable: 'apistring')])
        {
            echo 'checking number of changes and stopping job if nothing new happened'
            powershell 'powershell -File $env:WORKSPACE\\stop-script.ps1 -phrase "stop-job" -buildNumber $env:BUILD_NUMBER -gitprevious $env:GIT_PREVIOUS_SUCCESSFUL_COMMIT -gitcurrent $env:GIT_COMMIT -jenkinsUrl $env:JENKINS_URL -buildIDurl $env:BUILD_URL -apistring $env:apistring'
        }
    }
}
What is happening inside powershell script? There is needed to generate authorized POST call to Jenkins server, luckily is process few lines of code. Part of code is missing definition of parameters in Powershell.
if($phrase -eq "stop-job")
{       
    $commitsnumprevious = (git rev-list --count $gitprevious)
    $commitsnumactual = (git rev-list --count $gitcurrent)
    $difference =  $commitsnumactual-$commitsnumprevious

    if($difference -le 0)
    {
        $url = $buildIDurl+'stop'
        $Bytes = [System.Text.Encoding]::UTF8.GetBytes($apistring)
        $Base64bytes = [System.Convert]::ToBase64String($Bytes)
        $Headers = @{ "Authorization" = "Basic $Base64bytes"}
        $CrumbIssuer = "$jenkinsUrl/crumbIssuer/api/xml?xpath=concat(//crumbRequestField,`":`",//crumb)"
        $Crumb = Invoke-WebRequest -UseBasicParsing $CrumbIssuer -Headers $Headers
        $Regex = '^Jenkins-Crumb:([A-Z0-9]*)'
        $Matches = @([regex]::matches($Crumb, $Regex, 'IgnoreCase'))
        $RegCrumb = $Matches.Groups[1].Value
        $Headers.Add("Jenkins-Crumb", "$RegCrumb")

        try
        {
            $response = Invoke-WebRequest -Uri $url -Headers $Headers -Method POST
        }
        catch
        {           
            Write-Error "Stopping of job failed! " $_.Exception.Response.StatusCode.Value__
        }       
    }
}
I hope this few lines of code can make your day easier.
 

2018-09-10

Jenkins pipeline if-else for null variable

I was struggling few days with solving scripting problem in Jenkins Pipeline job definition. Since my Powershell scripts are using parameters from Jenkins and accepting of zero lenght / null values is problem in command line. So how to secure the script?

It was about variable $env:GIT_PREVIOUS_SUCCESSFUL_COMMIT whis is empty unless first run was actually successful, but you need to think about it in script definition. It's about one ternary operation in any normal scripting language, but not in Groovy which is used in Jenkins pipeline.

So how to do? Option one is stage based:
stage('First-run')
{
when { environment name: 'GIT_PREVIOUS_SUCCESSFUL_COMMIT', value: ''
}
steps
{
echo 'There is no successful previous build, need to run completely.'
}
}

stage('Regular-run')
{
when { not { environment name: 'GIT_PREVIOUS_SUCCESSFUL_COMMIT', value: '' }}
steps
{
echo "Regular run with ${GIT_PREVIOUS_SUCCESSFUL_COMMIT}"
powershell 'powershell -File $env:WORKSPACE\\script.ps1 -phrase "start" -buildNumber $env:BUILD_NUMBER -gitprevious $env:GIT_PREVIOUS_SUCCESSFUL_COMMIT -gitcurrent $env:GIT_COMMIT -jenkinsUrl $env:JENKINS_URL'
}
}
There you see that variable is checked for step block and block is executed only when variable fits. This solution sometimes not fulfill all requirements of condition, so there is also another solution for inside if-else expression.

stage('Everytime-run')
{
steps
{
script
{
if(env.GIT_PREVIOUS_SUCCESSFUL_COMMIT !=  null)
{
echo "PREVIOUS COMMIT IS NOT NULL - ${GIT_PREVIOUS_SUCCESSFUL_COMMIT}"
powershell 'powershell -File $env:WORKSPACE\\script.ps1 -phrase "start" -buildNumber $env:BUILD_NUMBER -gitprevious $env:GIT_PREVIOUS_SUCCESSFUL_COMMIT -gitcurrent $env:GIT_COMMIT -jenkinsUrl $env:JENKINS_URL'
}
else
{
echo 'PREVIOUS COMMIT IS NULL'
}
}
}

}
Exploration of these constructions took me lot of time, so I hope you can solve it without issues.

2018-08-07

Jenkins pipeline calls cmd command

When you need to call cmd command from Jenkins pipeline script you can do it in following way. I am just storing that piece of code here.
steps
  {  
   script
    {
     env.GitCurrentHash=bat(returnStdout: true, script: "@echo off | git --git-dir=${WORKSPACE}\\.git rev-parse origin/${branch}").trim()
    }
  
echo "Current Git Hash: ${GitCurrentHash}"
   echo "Current Git Hash: ${GIT_COMMIT}"
  }
 Sub-command "@echo off |" is there to eliminate repetition of command to system output console, so we see only command result.

If you want to collect git hash from file level use construction:
env.gitcurrent=bat(returnStdout: true, script: "@echo off | git --git-dir=${WORKSPACE}\\.git rev-parse HEAD 2> nul || echo githash").trim()

If you want to know branch name from file level use construction:
env.gitbranch=bat(returnStdout: true, script: "@echo off | git --git-dir=${WORKSPACE}\\.git name-rev --name-only HEAD 2> nul || echo gitbranch").trim()

 That's all... 

2018-04-16

Přesměrování IIS stránky na localhost

Na testovacím Windows serveru s IIS beží aplikace, která používá Apache na lokálním portu 8080, jak zpřístupnit tuto webovou stránku uživatelům, kteří se nenacházejí na serveru lokálně?

Server IIS (ver 10) hostí nějaké testovací aplikace pro platformu .Net a je potřeba mít IIS server funkční, zároveň to znamená, že IIS přebije konfiguraci standalone aplikace s Apache a je tedy potřeba předávat požadavek z vnějšího rozhraní na localhost a zpátky. 

Tohoto je možné dosáhnout založením "site" webové aplikace v konfiguraci IIS. Pod jejím jménem, které by mělo být v DNS bude aplikace přístupná světu. Poté v konfiguraci nalezněte URL Rewrite => Add Rule(s) => Reverse Proxy. Příchozí pravidlo obsahuje místo, kam bude požadavek přesměrován, tedy na localhost:8080 bez http, odchozí pravidlo zůstane nevyplněno.

V případě, že editujete existující pravidlo je nastavení, "Matches the Pattern", "Regular Expressions" a Pattern "(.*)" - bez uvozovek. Rewrite URL tak bude "http://localhost:8080/{R:1}", zaškrknuto Append Query String a Stop Processing subsequent rules.

Případně to lze také zařídit konfiguračním souborem web.config v kořenovém adresáři této webové aplikace. Stránka localhost:8080 je ta lokální a veřejné jméno se v konfiguraci nevyskytuje.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="ReverseProxyInboundRule" stopProcessing="true">
                    <match url="(.*)" />
                    <action type="Rewrite" url="http://localhost:8080/{R:1}" />
                </rule>
            </rules>
        </rewrite>
    </system.webServer>
</configuration>
Ověření konfigurace je prostým otevřením webovky. Objevuje-li se chyba 500 či obecně 5xx, pak je něco nakonfigurováno špatně na IIS, jde-li stránka na localhostu.

2018-03-15

How to let Jenkins to Run Powershell in x64 mode

Automation tool Jenkins is running as x86 service which means that its running all of the scripts under x32 mode - and that makes troubles to some cmdlets (extensions which are available only in x64).

I needed to run IIS stuff using "Import-Module WebAdministration" calling in .ps1 script, but by default is was throwing error.

So what I did, I spent long time by trying to found solution. After coupe of trials, I found that you need to use <SYSNATIVE> path to Powershell to be running on same as system architecture.

so instead of powershell.exe -File $env:WORKSPACE\x86-x64.ps1
I let to run  C:\Windows\sysnative\windowspowershell\v1.0\powershell.exe -File $env:WORKSPACE\x86-x64.ps1

What is not working

First at all nothing with Java, JRE, JDK etc. because it's not even installed on server - Jenkins is using encapsulated private JRE inside and it's not allowed to touch it. Don't put messy Java to your server when is not needed, you significantly decrease risk of security issue.

Secondly, you need to use path with sysnative, if you use standard path then is not working as well - see screenshots.








Thirdly, I tried to use relaunch powershell script to x64 (using $myInvocation.InvocationName) and it was changing running architecture, but since I am using parameters it wasn't working as well, because parameters get lost

Anyway

Where to found paths to all version of Powershell? Use system links at %APPDATA%\Microsoft\Windows\Start Menu\Programs\Windows PowerShell\

2016-06-15

GetSimple CMS na Wedosu

Při standardní instalaci redakčního systému GetSimple od verze 3.3.10+ na hosting Wedos nastane problém s chybou serveru díky kterému stránky nefungují.
Internal Server Error
Pri zpracovani pozadavku doslo k vnitrni chybe. Pravdepodobne se jedna o chybu v .htaccess souboru.
Ctete instrukce v nasi znalostni bazi: Chyba 500 - Internal Server Error

Pro prvotní zprovoznění je třeba zakomentovat křížkem v .htaccess souboru v kořenovém adresáři webu řádek
#Follow symbolink links, This is required for rewrites on some hosts

#Options +FollowSymLinks
Čímž dojde k oživení webu. Teď nastává už jen problém s přepisováním cesty, neboť GetSimple CMS detekuje, že jeho cesta k souborům na Wedosu je namísto
http://test.domain.tld/
taková
http://test.domain.tld/domains/test.domain.tld/
Tuto změnu proveďte přímo v administraci redakčního systému (test.domain.tld/admin), kde se nastavuje adresa webové prezentace.

Dále ve složce /data/uploads zakomentujte křížkem řádek SetHandler GS_DISABLED_SECURITY
#SetHandler GS_DISABLED_SECURITY
dojte tím k zprovoznění čtení souborů ze složky uploads

Dále jsem se dostal na neprůchozí hlášku:
Unable to open /data/web/virtuals/00000/virtual/www/domains/domain.tld/theme/
V tomto momentě se mi zobrazovala jenom bílá stránka bez chyby. Nedařilo se mi vytvořit novou stránku a to vše díky nedostupnosti souborů šablony ze složky /theme/, snažil jsem se to různě vyřešit, nakonec pomohlo až smazání všech souborů a jejich opětovné nahrání i se všemi výše uvedenými opravami.

Postupem času provádím další provozní vylepšení, pokud máte nějaký dotaz nebo chcete přispět svou troškou do mlýna, tak můžete v komentářích níže.

2016-01-04

Jaký je rozdíl mezi SDN, NFV a síťovou virtualizací?

Pokud se zajímáte o novinky v oblastech počítačových sítí, pak jste nutně museli narazil na "nové" pojmy, jejichž definice jsou dle mého trošku těžší v počátcích pochopit. Protože se touto oblastí zabývám v rámci svého magisterského studia, dovoluji si přijít s vysvětlením vlastními slovy.



IT je oblast, kde každá sebevětší kravinka má svou vlastní, obvykle třípísmennou, zkratku. Takže jejich rozepsání je následující:
  • SDN = Software-defined networking 
  • NFV = Network functions virtualization
  • NV = network virtualization
Cílem všech těchto pojmů je přejít ze stávajícího síťařského modelu, kdy každé dedikované zařízení má svou krabičku a v ní svou konfiguraci. Největší současná nevýhoda je totiž to, že se v provozní konfiguraci po čase reálného používání nikdo nevyzná. 

Hledat, jestli se spojení nesestaví, protože datagramy zahodí na vstupu firewall nebo uvnitř pravidlo nepovolující tento typ služby nebo na výstupu zákaz předat packety s konkrétní adresou na toto rozhraní a to vše v obou směrech a na všech zařízením po cestě je zkrátka moc velký hlavolam. Proto chcete mít centrální konfiguraci odkud je přehled nad celou sítí.



Navíc v době, kdy počet připojených zařízení roste vysokým tempem je klasický systém neudržitelný. Měl jsem možnost slyšet zkušenosti se správou univerzitní sítě VŠB a jednou severskou společností a jsem rád, že jsem za to nebyl zodpovědný...

Nový model "krabiček" ideálně bázi PC (i když to není nutnou podmínkou pro SDN controller) se sdílenou konfigurací, respektive s jedním místem odkud se nastavení provádí. Více o smyslu toho všeho v závěru příspěvku.


Software defined networking 

Je to takový přístup k architektuře, který se snaží využít abstrakce k správě síťové funkcionality. Logické topologie sítě se dosahuje pomocí programování virtuálních komponent. Principem je oddělení rozhodovací části (control plane) síťového prvku od té vykonávající směrovací či přepínací činnost (data plane).


Pro doplnění: Rozdíl mezi control (rovina řízení) a data plane (rovina obsluhy) je podobný problému městské hromadné dopravy. Control plane ve městě určí a dále sleduje, které linky povedou odkud kam a jaká na nich pojedou vozidla. Data plane jsou šoféři, kteří převážejí cestující.


Reálně už tento stav v každém zařízení dlouho existuje, roviny jsou odděleny. SDN ale říká, že control plane se vytvoří vně na jednom místě centrálně a nikoliv distribuovaně v každém zařízení. Data plane nahradit nelze, protože to je ta část, která vykonává skutečnou práci na základě pokynů "shora".



Trochu to může připomínat řízení firmy, máte svou manufakturu v jednom státě, vyrábíte několik užitečných věcí. Najednou celou firmu koupí větší globální firma, vyhodí vaše současné vedení a nařídí, že máte dělat jenom jeden produkt. Vy máte pocit, že "ti idioti" tomu vůbec nerozumí a přitom z vnějšího pohledu jde najednou celý business lépe.

Tato prezentace přirovnává sítě k architektuře staveb a vůbec SDN pěkně shrnuje.



Pojem SDN by ale neměl zasahovat do oblastí, které byly softwarem dlouho před objevem buzzwordu SDN v roce 2009. Objevují se totiž různé manipulace, které tvrdí, že každý software v síťovém prvku do SDN patří, že směrovací protokoly jako OSPF nebo BGP jsou SDN, že firewall a load ballancer jsou SDN atd. Některé firmy tyto myšlenky tak rozvinuly, že samotný "vynálezce" Martin Casado už sám vlastně neví...

Network functions virtualization

Podstatou virtualizovaných funkcí sítě je nebýt závislý na specifickém hardwaru, protože ten je drahý, obtížně nahraditelný a pomalu se instaluje. V současném světě cloudových řešeních chcete mít vše spustitelné na x86 procesorech tedy na normálních počítačích resp. serverech, které se dnes umí automatizovat / orchestrovat.



Proto ve své síti chcete opustit fyzická zařízení jako load balancery, firewally, IDSky, IPSky, VPN koncentrátory, atd. a všechno mít jako virtuální stroje v datacentru. S NFV přišli telekomunikační poskytovatelé služeb u kterých existovalo velké množství různých proprietárních hardwarových boxů. Z dnešního enterprise pohledu je mít vše spíše softwarové běžné.



SDN vs NFV

NFV je vhodným doplňkem SDN, ale není jeho nezbytnou součástí a naopak. Jinými slovy, jsou si vzájemně prospěšné. Zatímco SDN se zabývá chováním a logickou topologií sítě, NFV přenáší funkcionalitu z fyzických zařízení na virtualizované servery. To vše v zájmu přehlednější správy, nižších pořizovacích i operačních nákladů a hlavně pro méně komplikované změny za pochodu a vytváření nových prostředí a služeb.




Network virtualization

Jestliže SDN se zabývalo jednotnou konfigurací hardwaru síťových zařízení, pak síťová virtualizace kompletně převádí tato fyzická zařízení do softwaru. 





Podle společnosti VMware je síťová virtualizace nosič pro síťové vrstvy L2 - L7 ISO-OSI modelu. Má to tedy být věrný obraz síťových prvků a linek stejně, jako je virtuální server ve vztahu se serverem fyzickým. Osobně cítím toto pojetí jako nejintuitivnější možné uchopení stavu věcí.



Nicméně na každé z úrovní je možné do opět virtualizovat nebo spouštět transportní technologie, které mají v názvu "virtuální" čímž vniká docela dobrý zmatek v pojmech i výsledku. Příkladem budiž VLANy, VXLANy, VRF, VPN, MPLS... Virtualizace celých zařízení umožňuje opouštět tyto technologie a nahrazovat je celými virtuálními zařízeními, což je většinou jejich cíl. Záleží tedy na architektovi, jak danou problematiku zpracuje. Nevím jak vám, ale mě to silně připomíná film Počátek...


Shrnutí

Celá problematika je poněkud rozsáhlá a určitě ji neobsáhne jeden článek, globálním cílem budoucích sítí, všech zmíněných technologií a konceptů je dohnat vývoj, který se udál ve virtualizaci serverové / aplikační. Lze toho dosáhnout mimojiné také díky tomu, že stále roste výkon počítačů a není potřeba se již výhradně spoléhat na hardwarově specifická zařízení, protože jejich vyšší výkon je možné nahradit kvantitou x86 počítačů.


Výborná je tato prezentace ze které pochází i množství obrázků, které jste zde viděli.



Pokud máte dotazy či připomínky, jsou vám k dipozici komentáře pod tímto textem.

Další materiály

2015-12-13

LibSRTP: make: *** [runtest] Error 255

Toto je řešení problému s knihovnou librsrtp při kompilaci na Ubuntu Server 14.04.3 LTS x64 v neprodukčním prostředí. Je to útržek z práce na projektu.

cd /usr/src/
cd /usr/src/libsrtp
CFLAGS="-fPIC" ./configure --enable-pic 
make && make install
make runtest
#E: ./rtpw: couldn't open file /usr/share/dict/words
#E: make: *** [runtest] Error 255 

#solution
cd /usr/share/dict
tar zxvf linuxwords.1.tar.gz
rm linuxwords.1.tar.gz
mv linuxwords.1/linux.words ./words
rm -r linuxwords.1
cd /usr/src/libsrtp 

make runtest
#libsrtp2 test applications passed.

Nic více, nic méně, ale snad to adminům hledajícím na Google pomůže. 

2015-11-14

Základní konfigurace linuxového serveru

Nevím jak vy, ale největší nevýhoda linuxového světa je fakt, že si musíte neustále pamatovat, kde se co nastavuje. Proto mám hodně rád Windows, kde se ke všemu dá nějak doklikat a zároveň to lze udělat i přes Powershell, nicméně tato možnost na GNU/Linuxu není a tak nezbývá, než si to pamatovat nebo stále Googlit a protože mám svůj blog, tak se mi to dobře hledá na něm. 


Zde přináším nějaký základní list nastavení, které řeším téměř pokaždé.

#check network config
ifconfig eth0


#set fixed IP
nano /etc/network/interfaces
auto eth0
iface eth0 inet static 
  address 192.168.0.10
  netmask 255.255.255.0
gateway 192.168.0.1
up route add default gw 192.168.0.2 eth0
#restart networku - aplikace nastavení
/etc/init.d/networking restart


#oziveni internetu
#route add default gw {IP-ADDRESS} {INTERFACE-NAME}
route add default gw 192.168.0.2 eth0
#vmware NAT8 is using second ip in subnet

#add DNS resolvers
echo nameserver 8.8.8.8 > /etc/resolvconf/resolv.conf.d/base
echo nameserver 208.67.222.222 >> /etc/resolvconf/resolv.conf.d/base


#edit DNS resolvale name
nano /etc/hosts

192.168.0.1 mujserver
#change hostname - must be used same name as above!

nano /etc/hostname 

#back to homedir 

#alt+126
cd ~

#autoselect from GRUB

/etc/default/grub
sudo update-grub

#enable ROOT login via SSH

nano /etc/ssh/sshd_config
#zakomentuj krizkem
PermitRootLogin without-password
#just below it, add the following line:
PermitRootLogin yes
#then restart SSH:

service ssh restart

#connect USB FLASH
mkdir mnt/flash/
lsblk
mount /dev/sdb1 /mnt/flash
umount /mnt/flash


#SSH warning message to users AFTER login
#online generator
nano /etc/motd 

#SSH warning message to users BEFORE login
nano /etc/issue.net
#some banner
nano /etc/ssh/sshd_config
#uncomment line
Banner /etc/issue.net

Pokud by vás problematika zajímala, věnoval jsem se nastavování Linuxu ve své maturitní práci z roku 2012, která je dostupná také jako ebook.

2015-05-21

Instalace GUI na Windows Server Core 2012

Tak se mi podařila pěkná zlotřilost - po odebrání role (demotaci) řadiče domény Active Directory se mi z mého serveru vytratilo také GUI prostředí, respektive zůstalo v něm až do doby, než jsem provedl restart po patchování aktualizacemi.

Když ponechám stranou fakt, že se nemám ponětí, proč se odinstalovalo také grafické prostředí a to, že jsem po tomto výrazném zásahu server nerestartoval automaticky: Co s nastálou situací, která se stala samozřejmě v nejnevhodnější okamžik?

Předně zjištění, že se server objevil v Server Core instalaci. To se kromě deterministických metod dá poznat podle toho, že je k dispozici pouze příkazová řádka (cmd) a chybí PowerShell. Z této příkazové řádky jde pak spustit pouze několik základních konzolí pro správu. 

Ulita sconfig podobná IBMáckému Smittymu
Na internetu je mnoho návodů, všechny ale vycházejí nikoliv z edice Server Core, ale z Minimal Server Interface, kde je k dispozici PowerShell, který ovšem v Core verzi chybí. (moc nechápu proč, ale asi je to ze způsobu interpretace PowerShellu v operačním systému) Nelze tedy použít metody s příkazem Install-WindowsFeature!

Nebudu to dále zdržovat. Do blikající konzole vložte následující příkaz: (zdroj)
Dism /online /enable-feature /featurename:Server-Gui-Mgmt /featurename:Server-Gui-Shell /featurename:ServerCore-FullServer /featurename:ServerCore-FullServer /featurename:NetFx4 /featurename:NetFx4ServerFeatures /featurename:MicrosoftWindowsPowerShell /featurename:MicrosoftWindowsPowerShellRoot

Ten doinstaluje všechny komponenty grafického rozhraní a po restartu se server rozjede v plně grafickém režimu.


Vsuvka: 
Error: 50
The operation is complete but Server-Gui-Mgmt feature was not enabled. A required parent feature may not be enabled.
...znamená, že je třeba použít výše uvedený příkaz v celé délce i s podružnými fíčurami. Z fóra uvedené 2 mi plně nestačily.


P.S. možná vám takový přístup přijde laxní a máte pravdu. Tento postup jsem aplikoval na svém domácím serveru, kde nebyl ovlivněn žádný zákazník. V práci si dávám podstatně větší pozor...

2015-05-06

Referát na téma Cloud Computing

Dostal se ke mně požadavek na zpracování referátu středoškolské úrovně o cloud computingu, tedy o "pronájmu výpočetních počítačů". Úkolem bylo stručně vysvětlit o co jde, uvést výhody a nevýhody. Podmínkou bylo nekopírovat informace z internetu a použít vlastní slova, což se myslím podařilo, však posuďte sami.

S rozvojem internetu a zejména s jeho vysoko rychlostní dostupností koncovým uživatelům začalo být možné vzdáleně poskytovat, jinak typicky lokální služby. Jedním z prvních představitelných příkladů cloud computingu se stalo poskytování webhostingu, od něj to byl jen kousek k pronajímání diskového místa a odtud pak k provozování serverů. 

Pozor ale na rozdíl mezi cloudem a pouhým přesunutím zdrojů na jiné místo, který je v pružnosti cloudových řešení. Cloud computing je díky vyspělé technologii a především zvládnuté automatizaci schopný reagovat do několika sekund až minut na změněnou zátěž, případně je schopný velmi operativně poskytnou krátkodobý výpočetní výkon. 

Příkladem může být třeba server eshopu, který celý rok vydrží běžet na jednom serveru, který vlastníte nebo si jej někde pronajímáte. Jak ale budete řešit zvýšenou zátěž před Vánoci? Podle dřívějších konvencí byste si objednali zvětšení serveru, to by provedl váš poskytovatel nebo správce. Technicky je totiž původní server odstavit, provést úpravu a poté znova spustit. V případě používání správného cloudu stačí někde v administraci změnit výkonové parametry a server se bezvýpadkově překonfiguruje. Samozřejmě lze také nastavit, že v případě velkého zatížení dojde k této změně automaticky. Přistupující klienti nepoznají zvýšenou zátěž, vám nevypadne služba a rozdíl poznáte až na fakturě.

Jiný příkladem může být využití výpočetního výkonu pro jednorázové projekty. Zde si nemusím projekt vymýšlet, ale je možné použít příklad vývojářů ze zpravodajství iHned.cz, kteří dělali internetovou aplikaci na spočítání dojezdových časů pražské MHD. Ta má přes 3 000 zastávek, tedy někde kolem pěti milionů možných spojení. A každé spojení je hledání cesty v grafu, kde můžeme přestupovat i po ulicích pěšky. To celé potřebovali spočítat čtyřikrát – ve špičce a mimo špičku, před a po změně jízdních řádů. Jedno spojení se počítalo řádově sekundy, takže na vlastních serverech by novináři čekali přes půl roku na výsledek. A proto se rozhodli využít cloud od Amazonu, kdy za týden běhu servery napočítaly přes 9 měsíců compute time. Celý tento výpočet je stál 800 Kč. Rychlé i ekonomicky výhodné! A takových příkladů s dalším rozvojem cloudu stále přibývá.

Pokud jde o nevýhody využívání cloudových poskytovatelů je to především vaše závislost na internetovém připojení, toto ovšem platí zejména, pokud byste cloud využívali jako náhradu vnitropodnikových serverů. Taktéž se jako argument uvádí bezpečnost dat v něm uložených, poslední průzkumy však ukazují, že díky častým útokům na cloudová datacentera jsou vaše vlastní servery podstatně hůře zabezpečeny než jejich ekvivalenty patřící specializovaným provozovatelům. Totéž platí o výpadcích, poskytovatelé mají na rozdíl od vaší firmy několik datacenter rozmístěných po světě, takže ani živelná katastrofa neznamená ztrátu dat. Otázkou je pouze co se děje s vašimi důvěrnými daty umístěnými do cizích rukou. Provozovatelé proto mají nejrůznější certifikace pro manipulaci s citlivými informacemi. Komplikace nastávají, pokud vaše data nemohou opustit z nejrůznějších důvodů geografické území státu. Pak je třeba hledat mezi lokálními dodavateli, kterých na nejvyšší technikcé úrovni není mnoho. Dobré je připomenout, že po právní stránce náleží rozhodnutí o případném vydání dat policii, soudům státu ve kterém datacentrum leží, což může být ale v některých státech s vysokou mírou korupce výhoda. 

Zdá se tak, že největší viditelnou slabinou jsou finance, pokud byste se rozhodli cloud využívat dlouhodobě v řádech let, protože je v ceně zahrnut i potenciál pro pokrývání výkonových špiček. Pokud se na cloud podíváme i z druhé strany je zde poměrně velké riziko zneužití tak velkého a levného výkonu k útokům na jiné subjekty nebo například k prolamování hesel hrubou silou. Tyto kroky jsou v současnosti sledovány poskytovateli, kteří různými metodami sledují aktivity a vstupní čí výstupní provoz.

Cloud tak pokrývá současný trend na vysokou specializaci firem, kdy outsoursing nahrazuje vnitřní služby, které nejsou předmětem podnikání. Má velké množství výhod a několik nevýhod. Jesti se vám jeho používání vyplatí záleží na technicko-ekonomické analýze. Dá se však velmi rychle zahájit jeho používání, čehož u konvenčních postupů nelze dosáhnout.