Miten Dockerin ja CI/CD:n avulla vapautetaan sovellus tuotantoon?

Dockerin käyttö sovellusten kehityksessä ja julkaisussa mahdollistaa yhdenmukaisen ja toistettavan ympäristön rakentamisen, mikä sulkee perinteisen konfigurointikuilun. Konfiguroimalla projektin juureen Dockerfile, joka määrittelee sovelluksen ajonaikaisen ympäristön, luodaan elävä dokumentaatio koodipohjaan. Näin kehitystiimi varmistaa, että sovellus toimii samoin paikallisesti, testausympäristössä ja tuotannossa. Npm-skriptien, kuten npm run docker:debug ja npm run docker:publish, avulla automatisoidaan koko prosessi kuvien rakentamisesta, testaamisesta ja julkaisemisesta säilörekisteriin. Tämä automatisointi parantaa tuottavuutta ja vähentää virheiden mahdollisuutta.

On tärkeää ymmärtää, että Dockerin välimuisti saattaa kasvaa merkittävästi ajan myötä, joten sen hallintaan tulee kiinnittää huomiota komentoja kuten docker image prune ja docker container prune käyttäen. Tämä pitää levyaseman tilan hallittavana ja estää turhien datamäärien kertymisen. Lisäksi docker ps -komennolla kannattaa aina tarkistaa käynnissä olevat säilöt, niiden käyttämät portit sekä päivitysaikataulut, jotta ei synny päällekkäisyyksiä tai konflikteja.

Pilvipalveluihin konttien sijoittaminen on luonteva jatkumo kehityksen automatisoinnissa. Pilvipalveluntarjoajat kuten Azure, AWS ja Google Cloud tarjoavat laajan kirjon palveluita konttien ajamiseen, aina hallituista palveluista itsehallittuihin virtuaalikoneisiin. Hallitussa ympäristössä pilvipalveluntarjoaja vastaa suuresta osasta infrastruktuurin ylläpitoa, tietoturvasta ja päivityksistä, mikä vapauttaa käyttäjän keskittymään sovellukseen. Tämä vastuunjako tunnetaan nimellä Shared Responsibility Model. Toisaalta itsehallinnoitavassa mallissa käyttäjä hallitsee käyttöjärjestelmää ja konttiklustereita kokonaisuudessaan, mikä vaatii syvempää teknistä osaamista mutta antaa täydellisen kontrollin ympäristöön.

On hyvä tiedostaa, että pilvessä konttien pyörittäminen vaatii huolellista suunnittelua tietoturvan näkökulmasta. Erityisesti orkestrointijärjestelmien, kuten Kubernetesin, konfigurointi ja pääsynhallinta ovat kriittisiä komponentteja. Julkisten pilvipalveluiden tarjoamat työkalut ja palvelut voivat auttaa tämän hallinnassa, mutta kokonaisvastuu jää aina käyttäjälle, mikä korostaa jatkuvan valvonnan ja päivitysten merkitystä.

Yhteenvetona voidaan todeta, että Dockerin ja siihen liittyvien työkalujen hyödyntäminen CI/CD-putkissa ei pelkästään automatisoi julkaisuprosessia vaan myös tuo mukanaan selkeyttä, toistettavuutta ja turvallisuutta koko sovelluskehityksen elinkaaren ajaksi.

Miten parantaa suorituskykyä suurissa web-sovelluksissa?

Suorituskyvyn ongelmat suurissa web-sovelluksissa voivat olla monisyisiä ja haasteellisia ratkaista. Web-sovelluksen käynnistysprosessiin liittyy useita vaiheita, jotka vaikuttavat sen nopeuteen ja tehokkuuteen. Yksi keskeisimmistä vaiheista on JavaScriptin lataaminen, joka voi sisältää sovelluksen, kehyksen ja kolmannen osapuolen kirjastoja. Mitä suurempi koodi on, sitä pidempään sen lataaminen kestää. Tämä on usein ensimmäinen hidastumisen syy.

Kun JavaScript on ladattu, sen täytyy purkaa ja ladata muistiin, ennen kuin se voidaan käsitellä JavaScript-moottorilla ja suoritettavaksi ajonaikaisesti. Tässä vaiheessa DOM-elementit ja kehyksen koukut täytyy myös luoda ja liittää. Seuraavaksi sovelluksen tilan (sekä visuaalisen että datan) laskeminen, tapahtumankuuntelijoiden liittäminen DOMiin ja komponenttien renderöinti lisäävät entisestään suorituskyvyn haasteita. Viimeisenä vaiheena on tilan muutoksen tarkistaminen, jossa kehys käy läpi komponenttipuun ja tarkistaa, pitääkö käyttöliittymää päivittää tilan muutoksen takia.

Nämä vaiheet suoritetaan peräkkäin, ja jos sovellus tai API-koodi ei sisällä suuria virheitä, ne muodostavat suorituskyvyn pullonkauloja suurissa sovelluksissa. Nykyisissä SPA-kehyksissä (Single Page Application) tällaiset ongelmat ovat väistämättömiä ja niiden ratkaiseminen on usein kallista. Esimerkiksi liian monen interaktiivisen komponentin renderöiminen kerralla voi olla käytännössä ratkaisematon ongelma, ja erittäin kallis ratkaisu voi olla jokaiseen komponenttiin lisätä mukautettua koodia, joka ohittaa kehyksen normaalin elinkaaren ja pakottaa sen käyttäytymään tietyllä tavalla. Tämä ei kuitenkaan aina ole käytännöllinen ratkaisu.

Minimalistiset JavaScript-ratkaisut, kuten ECMAScript 2022:n uudet ominaisuudet, tarjoavat mahdollisuuden luoda suorituskykyisiä ja reaktiivisia web-sovelluksia hyvin vähällä koodilla. Näitä ratkaisuja käyttämällä voimme parantaa kehittäjäkokemusta (DevEx) ja luoda moderneja ja nopeita verkkosivustoja, joiden "kehys" on vain 1-2 kb kokoinen. ArrowJS on esimerkki tällaisten ratkaisujen käytöstä, jossa hyödynnetään JavaScriptin ominaisuuksia kuten WeakMap, Proxy, Set ja Tagged template literals. Nämä mahdollistavat reaktiivisuuden ilman raskasta kehystä, jolloin sovelluksen kehittäminen on nopeampaa ja suorituskyky parempi.

Toinen esimerkki on Qwik.js, joka on suunniteltu vastaamaan suuriin SPA-kehyksiin liittyviin ongelmiin, kuten Angularin, Reactin ja Vue:n haasteisiin. Qwik.js on kehitetty tarjoamaan reaktiivisen koodauksen periaatteet ja sisäänrakennetun tilan hallinnan, joka mahdollistaa sovellusten latautumisen alle sekunnissa ja parantaa suorituskykyä jopa 5-10 kertaa verrattuna perinteisiin kehyksiin. Qwik.js:ssä hyödynnetään "resumability"-ominaisuutta, joka erottuu perinteisestä hydratoitumisesta. Resumable-sovellus ladataan valmiiksi renderöitäväksi HTML-payloadiksi, jolloin suorituskyvyn haasteet vähenevät merkittävästi.

Tässä suhteessa Qwik.js on innovatiivinen. Sen lisäksi, että se käyttää hyvin kevyitä JavaScript-kirjastoja (~1kb), se lataa vain tarvittavat osat koodista ja suorittaa ne vain silloin, kun käyttäjä vuorovaikuttaa sovelluksen kanssa. Tämä on mahdollista älykkäiden esilatausalgoritmien avulla, jotka varmistavat sujuvan käyttökokemuksen. Qwik.js tarjoaa lisäksi täyden tuen server-side renderingille (SSR), mikä nopeuttaa sovelluksen lataamista ja tekee siitä yhteensopivan hakukoneoptimoinnin (SEO) kanssa.

Angular-sovellusten suorituskyvyn parantamiseksi on olemassa useita ratkaisuja, joista tärkeimmät liittyvät sovelluksen alkulatauksen optimoimiseen sekä sujuvan renderöinnin varmistamiseen muutoksen tarkistuksen avulla. Server-side rendering (SSR) on yksi tehokas tapa parantaa suorituskykyä, koska se mahdollistaa sovelluksen esirenderöinnin palvelimella, mikä vähentää selaimessa tapahtuvaa JavaScriptin tulkintaa ja parantaa latausnopeutta. Tämä on erityisen tärkeää mobiililaitteilla tai vanhemmilla laitteilla, joissa prosessointiteho ja kaistanleveys ovat rajoitettuja. Serveri voi hoitaa tämän tehtävän tehokkaasti, riippumatta käyttäjän laitteista.

Seuraavaksi, kun käyttäjät siirtyvät sovellukseen ja sen sisältöä muokataan, on tärkeää huolehtia siitä, ettei muutoksen tarkistus (change detection) käy liian raskaaksi ja jää jumiin. Tämä voi olla erityisen haasteellista suurissa sovelluksissa, joissa on paljon interaktiivisia komponentteja. Suorituskyvyn ylläpitämiseksi on tärkeää optimoida komponenttien elinkaaren hallinta ja varmistaa, että vain ne komponentit, jotka todella tarvitsevat päivitystä, saavat sen.

Kun kaikki nämä tekijät otetaan huomioon ja käytetään oikeita työkaluja ja tekniikoita, kuten SSR, reaktiiviset kirjasto- ja kehysratkaisut sekä älykkäät latausalgoritmit, voidaan merkittävästi parantaa suurten web-sovellusten suorituskykyä ja käyttäjäkokemusta.

Kuinka tehokkaasti käyttää wikia ja mock-uppeja ohjelmistokehityksessä?

Kun luot wikipohjaa GitHubissa, on tärkeää huolehtia sisällön linkittämisestä. Muista linkittää wikiin kaikki saatavilla oleva dokumentaatio, kuten Readme-tiedostot, jotta käyttäjät pääsevät helposti käsiksi kaikkiin tarvittaviin tietoihin. GitHubin wiki näyttää alatason sivut oikealla olevassa navigointiosassa, mutta joillekin käyttäjille tämä voi jäädä huomaamatta. Tästä syystä on hyvä lisätä yhteenveto, kuten esimerkiksi "Design Artifacts" -osio, jotta kaikilla on selkeä käsitys, mistä sisältö löytyy.

Kun olet luonut mock-upit, lisää ne wikiin. Tämä antaa tiimillesi selkeän kuvan siitä, millaisia näkymiä sovelluksessa on odotettavissa. Esimerkiksi LemonMartin mock-upit voivat auttaa hahmottamaan sovelluksen käyttökokemusta ja virtausta, vaikka sovelluksen toiminnallisuus ei ole vielä täysin valmis. Mock-upit voivat myös olla erittäin hyödyllisiä, kun testaat ja kehität sovelluksen toiminnallisuutta varhaisessa vaiheessa.

Wiki toimii elävänä dokumentaationa, jossa tiimin jäsenet voivat muokata, päivittää ja lisätä sisältöä. Tämä poistaa sen tunnetun ongelman, jossa dokumentaatio tuntuu olevan vain pakkopullaa eikä tiimille tarpeellista. Kun dokumentaatio on helposti saatavilla ja sen ylläpitäminen on helppoa, siitä tulee olennainen osa tiimin työskentelyprosessia. On tärkeää ymmärtää, että wiki ei ole vain paikkansapitävä dokumentti, vaan se on osa jatkuvaa yhteistyötä ja kommunikaatiota tiimin jäsenten välillä.

Mock-upit voidaan lisätä myös itse sovellukseen, niin että testikäyttäjät voivat paremmin ymmärtää sovelluksen virtausta ja toiminnallisuuksia, jotka eivät ole vielä toteutettuina. Tämä on erityisen tärkeää, kun suunnitellaan ja toteutetaan käyttöoikeus- ja autentikointivirtoja. Esimerkiksi sovelluksen virhetilanteet ja virheilmoitukset voivat jäädä helposti huomaamatta, jos niitä ei ole selkeästi visualisoitu. Samalla voidaan myös tarkistaa, miten käyttöliittymä reagoi eri käyttäjärooleihin ja -oikeuksiin.

LemonMartin sovelluksessa on tarkoitus toteuttaa backend, joka mahdollistaa käyttäjän tunnistamisen ja käyttöoikeuksien hallinnan. Tämä vaihe tulee käsiteltäväksi seuraavissa luvuissa, jotka keskittyvät autentikointiin ja roolipohjaiseen navigointiin. Näiden vaiheiden avulla kehittäjät voivat luoda turvallisen ja käyttäjäystävällisen autentikointijärjestelmän, joka takaa sen, että käyttäjät voivat suorittaa vain ne toiminnot, joihin heillä on oikeus.

Kun autentikointijärjestelmä on suunniteltu ja toteutettu, on tärkeää, että se on helposti laajennettavissa ja ylläpidettävissä. Kehittäjien on tärkeää huomioida, että autentikoinnin ja valtuutuksen virhetilanteet voivat johtaa käyttäjien turhautumiseen, mikä vaikuttaa sovelluksen luotettavuuteen ja käyttäjäkokemukseen. Tässä kohtaa ohjelmistokehittäjien on otettava käyttöön hyvän ohjelmoinnin periaatteet, kuten OOP-konseptit, abstrahointi ja perintö, jotta toteutus on selkeä ja helposti ylläpidettävä.

Kun sovelluksen käyttöliittymä ja autentikointijärjestelmä ovat valmiita, käyttäjäkokemus voi olla luotettava ja sujuva. On kuitenkin tärkeää, että testaamme ja keräämme palautetta varhaisessa vaiheessa. Tämä voi auttaa tunnistamaan mahdollisia virhetilanteita tai käyttäjävirheitä, jotka muuten voisivat jäädä huomaamatta.

Kaiken kaikkiaan on tärkeää ymmärtää, että mock-upit, wiki ja hyvin suunniteltu autentikointijärjestelmä ovat keskeisiä osia, jotka tukevat sovelluksen kehitystä ja helpottavat tiimin työtä. Hyvä dokumentaatio ja selkeä suunnittelu tekevät sovelluksesta helposti ylläpidettävän ja laajennettavan, mikä on olennaista, kun sovellus kasvaa ja kehittyy.

Firebase-authentikointi ja sen integrointi Angular-sovellukseen

Firebase on suosittu ja tehokas työkalu, joka mahdollistaa käyttäjäautentikoinnin sekä tietoturvallisuuden hallinnan helposti integroitavassa muodossa. Tässä luvussa tarkastellaan, miten Firebase authentication -palvelu voidaan integroida Angular-sovellukseen hyödyntäen olemassa olevaa abstraktia autentikointipalvelua ja laajentamalla sen toiminnallisuuksia. Tämä lähestymistapa mahdollistaa autentikoinnin hallinnan ilman merkittäviä koodimuutoksia, koska ainoastaan Firebase:n autentikointimetodit yhdistetään olemassa olevaan palveluun.

Ensimmäinen askel Firebase-authentikoinnin käyttöönotossa on laajentaa abstraktia AuthService-palvelua. Tämä tapahtuu luomalla uusi FirebaseAuthService-luokka, joka ottaa vastaan käyttäjän kirjautumistiedot ja yhdistää ne Firebase:n tarjoamaan autentikointipalveluun. Koodissa käytetään signInWithEmailAndPassword-metodia kirjautumiselle ja signOut-metodia uloskirjautumiselle.

typescript
Copy code
import { inject, Injectable } from '@angular/core'

import { Auth as FireAuth, signInWithEmailAndPassword, signOut, User as FireUser } from '@angular/fire/auth'

import { Observable, of, Subject } from 'rxjs'

import { IUser, User } from '../user/user/user'
import { Role } from './auth.enum'
interface IJwtToken {
  email: string
  iat: number
  exp: number
  sub: string
}
@Injectable()

export class FirebaseAuthService extends AuthService {

  private afAuth: FireAuth = inject(FireAuth)
  constructor() {
    super()
  }
  protected authProvider(email: string, password: string): Observable<IServerAuthResponse> {

    const serverResponse$ = new Subject<IServerAuthResponse>()

    signInWithEmailAndPassword(this.afAuth, email, password).then(
      (res) => {

        const firebaseUser: FireUser | null = res.user

        firebaseUser?.getIdToken().then(
          (token) => serverResponse$.next({ accessToken: token } as IServerAuthResponse),
          (err) => serverResponse$.error(err)
        )
      },
      (err) => serverResponse$.error(err)
    )
    return serverResponse$
  }
  protected transformJwtToken(token: IJwtToken): IAuthStatus {
    if (!token) {
      return defaultAuthStatus
    }
    return {

      isAuthenticated: token.email ? true : false,

      userId: token.sub,
      userRole: Role.None,
    }
  }
  protected getCurrentUser(): Observable<User> {
    return of(this.transformFirebaseUser(this.afAuth.currentUser))
  }
  private transformFirebaseUser(firebaseUser: FireUser | null): User {
    if (!firebaseUser) {
      return new User()
    }
    return User.Build({
      name: {
        first: firebaseUser?.displayName?.split(' ')[0] || 'Firebase',

        last: firebaseUser?.displayName?.split(' ')[1] || 'User',

      },
      picture: firebaseUser.photoURL,
      email: firebaseUser.email,
      _id: firebaseUser.uid,
      role: Role.None,
    } as IUser)
  }
  override async logout() {
    if (this.afAuth) {
      await signOut(this.afAuth)
    }
    this.clearToken()
    this.authStatus$.next(defaultAuthStatus)
  }
}

Kuten edellä olevasta koodista voidaan huomata, olemme toteuttaneet vain eron olemassa olevan autentikointikoodimme ja Firebase:n autentikointimetodien välillä. Ei ole tarvinnut kopioida koodia, vaan olemme yksinkertaisesti muuntaneet Firebase-käyttäjäobjektin sovelluksemme sisäiseksi käyttäjäobjektiksi. Tässä transformFirebaseUser-metodissa asetamme rooliksi Role.None, koska Firebase:n autentikointi ei oletusarvoisesti tue käyttäjäroolien käsittelyä.

Firebase-integraation saattamiseksi täysin toimivaksi on kuitenkin välttämätöntä laajentaa Firebase-toimintoja ja käyttää Firestore-tietokantaa käyttäjäprofiilien tallentamiseen sekä CRUD-operaatioiden suorittamiseen. Tässä vaiheessa, käyttäjän kirjautumisen jälkeen, olisi tehtävä toinen kutsu, jolla haetaan roolitiedot. Tämän osan toteuttamisesta keskustellaan tarkemmin luvussa 7, jossa käsitellään REST- ja GraphQL-rajapintojen käyttöä.

Kun Firebase-authentikointi on integroitu, on seuraava askel päivittää AuthService-provider app.config.ts-tiedostossa siten, että se käyttää FirebaseAuthService-luokkaa:

typescript
Copy code
{ provide: AuthService, useClass: FirebaseAuthService }

Tämän jälkeen voit lisätä uuden käyttäjän Firebase-authentikointikonsolissa ja kirjautua sisään käyttämällä oikeaa autentikointia. On tärkeää muistaa aina käyttää HTTPS:ää, kun siirrät henkilötietoja tai salasanoja verkossa, sillä muuten tietosi voivat päätyä kolmansille osapuolille tai joutua kyberhyökkääjien kaappaamiksi.

Kun integroit Firebase-authentikoinnin sovellukseen, tulee varmistaa, että kaikki mahdolliset virhetilanteet, kuten epäonnistuneet kirjautumisyritykset, käsitellään asianmukaisesti. Tämä takaa paremman käyttäjäkokemuksen ja parantaa sovelluksen luotettavuutta.

Miksi Docker takaa sovellusten toimintaympäristön yhdenmukaisuuden?

Docker tarjoaa kehittäjille ja operatiivisille tiimeille mahdollisuuden minimoida ympäristöjen erot, jotka usein aiheuttavat ongelmia sovellusten käyttöönotossa ja ylläpidossa. Kun koodi toimii paikallisessa kehitysympäristössä, Dockerin avulla voidaan varmistaa, että se toimii identtisesti myös tuotantoympäristössä. Tämä saavutetaan konttiteknologian avulla, joka kapseloi sovelluksen ja sen riippuvuudet yhteen pakettiin, jolloin ympäristön eroavaisuudet eivät vaikuta sovelluksen toimintaan.

DevOps-käytännöissä Docker toimii siltana kehityksen ja operaatioiden välillä, tuoden nämä kaksi perinteisesti erillistä toimintoa lähemmäksi toisiaan. Muutosten tekeminen ja virheiden korjaaminen on helpompaa ja edullisempaa silloin, kun sovellusympäristöt ovat yhdenmukaisia ja toistettavissa. Vaikka DevOps on ensisijaisesti kehittäjien vastuulla, se edellyttää myös operatiivisen tiimin sitoutumista ja yhteistyötä.

Docker on avoin alusta, joka tarjoaa kevytkonttien virtualisointiin perustuvan ympäristön sovellusten kehittämiseen, siirtämiseen ja ajamiseen. Toisin kuin perinteiset virtuaalikoneet, joiden koko on usein useita kymmeniä gigatavuja ja jotka kuluttavat merkittävästi muistia, Docker-kontit ovat kooltaan megatavuja ja vievät vähemmän resursseja. Tämä tehokkuus johtuu siitä, että Docker hyödyntää isäntäjärjestelmän ydintä ja jakaa sen resurssit useiden konttien kesken, jolloin ylimääräinen raskas virtualisointikerros puuttuu.

Dockerfile on keskeinen osa konttien hallintaa. Se sisältää neljä pääosaa: FROM, jossa määritellään pohjakuva; SETUP, jossa asennetaan sovelluksen riippuvuudet; COPY, jolla kopioidaan rakennettu sovellus konttiin; ja CMD, jossa määritellään käynnistysohjeet kontille. Esimerkiksi nginx-web-palvelimen sisältävä Dockerfile voi periä kevyen Alpine Linux -kuvan ja kopioida sovelluksen tiedostot palvelimen juurihakemistoon, jolloin palvelin tarjoaa sovelluksen käyttäjille.

Pohjakuva voi olla hyvin minimalistinen, kuten Alpine Linux, joka on vain muutaman megatavun kokoinen ja sisältää vain välttämättömimmät järjestelmäkomponentit ilman käyttöliittymää tai ylimääräisiä työkaluja. Tämän ansiosta lopullinen Docker-kuva pysyy pienenä, mikä nopeuttaa siirtoa ja käynnistystä sekä pienentää hyökkäyspintaa. Kontin turvallisuutta lisää myös se, että sovellus suoritetaan eristetyssä ympäristössä, mikä vaikeuttaa mahdollisten haavoittuvuuksien hyödyntämistä isäntäjärjestelmää vastaan.

Docker Hub tarjoaa julkisia kuvia, joiden perusteella voi jäljittää kuvan perimän aina pohjakuvasta lähtien. Tämä avoimuus auttaa kehittäjiä ymmärtämään, mitä heidän käyttämänsä kontit sisältävät, ja varmistamaan, että ne täyttävät heidän tarpeensa ja turvallisuusvaatimuksensa. On suositeltavaa valita kuvien versiot huolellisesti; evergreen-tyyppiset versiot päivitetään automaattisesti uusilla korjauksilla, mutta ne voivat sisältää myös riskejä yllättävistä muutoksista. Versioitu kuva tarjoaa vakaan ympäristön, mutta vaatii huolellisen testaamisen päivitysten yhteydessä.

On tärkeää ymmärtää, että Docker ei yksin ratkaise kaikkia sovelluksen turvallisuus- tai vakauskysymyksiä, vaan se on osa kokonaisvaltaista DevOps-käytäntöä, joka edellyttää huolellista hallintaa, jatkuvaa seurantaa ja yhteistyötä kehittäjien ja operatiivisten tiimien välillä. Docker-konttien taustalla oleva Linux-järjestelmä on minimalistinen, ja siksi sovelluksen turvallisuus riippuu myös sen sisältämistä konfiguraatioista ja käytetyistä ohjelmistoista. Kuvia kannattaa valvoa ja päivittää säännöllisesti, jotta niihin ei pääse kertymään tunnettuja haavoittuvuuksia.

Dockerin tehokkuus syntyy sen kyvystä kapseloida sovellus ympäristöineen helposti siirrettävään ja toistettavasti käynnistettävään muotoon. Tämä muuttaa merkittävästi sovelluskehityksen ja ylläpidon dynamiikkaa, kun sovellusten ympäristöt eivät enää ole riippuvaisia isäntäjärjestelmän ominaisuuksista tai manuaalisista konfiguraatiovaiheista.