Skip to main content

e24Cloud Struktura skalowalnego serwisu WWW

Przy okazji konkursu chmurowisko (https://chmurowisko.pl/e/) postanowiłem stworzyć przykładowy serwis WWW na chmurze e24cloud.com.

Tworząc złożone serwisy WWW myślimy, że nasz projekt będzie stać zawsze. Nikt ani nic nam nie zagraża. Okazuje się, że serwis może bardzo szybko zniknąć z internetu, i ciężko szybko go przywrócić do działania.

Powody, kiedy serwis może zniknąć z sieci:

  • atak na serwer (np DDOS)
  • nagły wzrost liczby użytkowników (np z 1000 do 100 000 dziennie)
  • złe wdrożenie poprawek na serwerze (czynnik ludzki)
  • awaria serwera
    • administrator coś nabroił, lub…
    • w serwerze popsuły się elementy, które są ważne
  • awaria całego regionu (całej firmy hostingowej)
    • serwer może działać, ale błąd w serwerowni nie pozwala dostać się do niego dostać
    • problemy z łączem do serwerowni (ile to się razy zdarzało, że pan w koparce przerwał światłowód)

Powyżej znajduje się kilka propozycji co może się stać. Powodów, może być mnóstwo. Jak zwiększyć szanse, że nasza strona będzie widoczna zawsze?

Założenia architektury o wysokiej dostępności / Korzyści

  • stworzenie serwisu znajdującego się na różnych serwerach / w różnych regionach
  • stworzenie backupu danych (zabezpieczenie przed zniszczeniem serwera lub błędu programisty)
  • możliwość łatwego podnoszenia parametrów serwera lub dokładanie nowych serwerów aby rozproszyć obciążenie

Rozwiązanie?

  • wykorzystanie dwóch regionów w serwerowni e24cloud (warszawa, poznań)
  • load balancer z wykorzystaniem docker swarm
  • replikacja bazy danych mysql (master-master)
  • synchronizacja plików między serwerami, aby dane zawsze były najbardziej aktualne

Jak wyżej wskazałem, postanowiłem postawić testowego bloga z wykorzystaniem docker swarm. 

Co to jest docker? jest to narzędzie umożliwiające nam odpalenie izolowanych kontenerów z całym środowiskiem / narzędziami, które potrzebujemy. Założeniem jest aby 1 oferował 1 usługę (baza danych, serwer www, itp).

Docker Swarm to jedno z nowych rozwiązań klastrowych, które pozwala umieszczać kopie kontenerów na różnych hostach. Swarm zapewnia również load balancer, a więc rozdziela ruch na x hostów, oraz jakich host jest nie dostępny, to jest on wykluczany i nie jest kierowany na niego ruch.

Opłacalność / Automatyzacja / Skalowalność

Przyjmijmy, że jeden serwer obsługuje cały serwis WWW. Dążymy do ochrony danych, i wysokiej dostępności serwisu. Czyli dostawiamy kolejne serwery.

Koszt testowego serwera odpalonego w e24cloud (1 rdzeń, 1gb ram, 40gb dysk) to 6.72 zł netto na tydzień.

Zakładając minimum 2 hosty, po 1 na region, to koszt tygodniowy wynosi 13,44 zł netto.

Transfer 100GB kosztuje 0.45 zł netto

Backup danych to za 1GB 0.0015 zł . A więc warto robić backup! 

Możemy konfiguracje mocno zoptymalizować. np:

  • posiadamy 4 hosty
  • na 2 hostach znajduje się baza danych
  • na 4 hostach znajduje się serwer www
  • na 1 hoście znajduje się cron z zadaniami

Gdy host pada, tworzony jest nowy kontener bazodanowy na innym dostępnym hoście. Tak aby nadal się znajdowały się 2 bazy danych.

E24cloud umożliwia automatyczne skalowanie serwera w górę. Dla ustawionych parametrów obciążenia ustawiamy zwiększenie Ilości procesorów / Ramu. To samo możemy zrobić jak obciążenie spada i chcemy słabszą maszynę. Jeden minus? Host jest niedostępny na 3-5 minut. Plus? Cena. Serwer o wyższych parametrach jest tańszy niż 2 gorsze.

Innym rozwiązaniem dzięki dockerowi, jest możliwość skalowania wszerz. Czyli dostawiamy kolejne maszyny i obciążenie jest rozpraszane na inne hosty. Plusy? Ciągłość dostępności serwisu jest zachowana. Minusy? Trzeba to zautomatyzować samodzielnie dla większego ruchu.

Co daje połączenie skalowania w górę i wszerz? Połączenie plusów z obu metod. Tańsze koszty + zmniejszone ryzyko niedostępności serwisu.

Tworzenie środowiska

Całkowity opis tworzenia środowiska z wykorzystaniem swarm wrzuce w kolejnych postach. Teraz skupię się na najbardziej głównych elementach.

Tworzenie hostów w dwóch regionach oraz powiązania docker swarm

Tworzymy dwa hosty, w regionie warszawa, oraz w regionie poznań. E24cloud obsługuje tworzenie obrazów serwera.Wcześniej stworzyłem serwer, zainstalowałem dockera (+ narzędzia do dockera) na serwerze, a następnie stworzyłem obraz instalacyjny. Teraz jak tworze nowy serwer, to wybieram obraz „docker+compose”. Nie tracimy czasu na instalacje oprogramowania w każdym serwerze.

 

Pod dodaniu hosta 1 dodajemy host 2 do drugiego regionu.

Teraz jak juz mamy działające 2 serwery, musimy je połączyć. Logujemy się na [host1], i tworzymy 1 węzeł główny.

 

Po wywołaniu polecenia pojawi się nam polecenie do skopiowania, aby połączyć drugą maszyne do pierwszej.Odpalamy to polecenie na [host2].

Wyjaśniając, 1 maszyna jest tzw „Manager”, a co za tym idzie, może kontrolować wszystko co znajduje się na wszystkich maszynach.

Druga maszyna jest „Gość”, i przyjmuje tylko polecenia.

Można tak zrobić, że każdy serwer jest managerem. Jednak teraz pominę tą opcje.

Tworzymy sieć, gdzie łączyć będziemy wszystkie kontenery ze sobą

Wgrywanie bazy danych i serwisu www

Tworzymy bazę klucz-wartość gdzie będą przechowywane informacje o istniejących kontenerach bazodanowych (w celu automatycznej replikacji danych nowo tworzonych instancji)

Wykorzystujemy percona-xtradb-cluster, która zostanie wgrana na dwa hosty po 1 instancji (replicas 2)

Mamy bazę danych z replikowaniem danych, pozostaje nam jeszcze stworzenie czystej instancji wordpress, która łączy się z klastrem bazodanowym

I… KONIEC :) 

Kilku poleceń nie dałem. Jednak przeglądając notatki, całe środowisko swarm zostało skonfigurowane w 10 poleceniach. Najważniejsze jednak to połączenie wszystkich hostów i kontenerów ze sobą co pokazałem powyżej.

Co jeszcze? Mogę dodać?

Automatyczny backup danych hosta

 

Automatyczne skalowanie hosta w górę lub dół

Podsumowanie

Każde rozwiązanie posiada plusy i minusy. Jak można zauważyć, bardzo łatwo utworzyć środowisko sprzętowe, oraz wrzucić oprogramowanie. Co jest najtrudniejsze? Zachowanie integracji danych. Czy będziemy używać docker swarm, czystych serwerów, lub innych rozwiązań, zawsze musimy zadbać o synchronizacje danych między hostami. O replikacje bazy danych. O miejsce gdzie wspólne rzeczy są zapisywane razem dla wszystkich hostów. Nie możemy pozwolić aby użytkownicy zobaczyli różnice między hostami.

Jest sporo rozwiązań używających docker swarm. Ja użyłem najprostszej. Domyślnie działa jak należy. Jednak jak wszystko z domyślnymi ustawieniami należy jeszcze to dobrze skonfigurować, aby nic nas nie zaskoczyło w przyszłości.

 

 

 

Docker, kilka wskazówek

Przy bawieniu się dockerem, testowaniu, wielokrotnym odpalaniu środowisk, zdarza się ze nic nie chce działać.

Czemu?

Odpalanie testowych środowisk powoduje ze ściągamy zcachowane warstwy, lub generujemy nowe. Ponowne generowanie, drobne zmiany itp powodują dwa problemy:

  • ilość miejsca na serwerze maleje
  • obraz środowiska, który chciałbyś odpalić od zera powinieneś usunąć i odpalić jeszcze raz

Gdy odpalamy dockera:

to zostają ściągnięte wszystkie warstwy (layers) potrzebne do zbudowania środowiska. Jeśli budujesz środowisko, to jest ono budowane lokalnie.

Normalnie możesz zatrzymać kontenery:

lub całkowicie je usunać:

Czym to się różni?

Jeśli tworzysz nowy kontener, dla jednego obrazu, prawdopodobnie posiada on skrypty inicjujące, które ustawiają wszystko co trzeba do jakiegoś systemu (np system do zarządzania zadaniami Redmine). Kontenery również zapisują dane wewnątrz siebie dane (jeśli nie wyprowadziłeś ich na zewnątrz).

Aby nie stracić tych ustawień, można zastosować STOP. (np wchodzisz w dany kontener i instalujesz coś ręcznie, i się bawisz poznając nowe rzeczy, dzięki stop tego nie stracisz)

Nie powinniśmy zapisywać jednak danych wewnątrz kontenera. Powinniśmy wyjść z założenia, że cokolwiek w nim jest, można usunąć i zresetować do stanu początkowego.

Dlatego jak nie bawię się, lub nie instaluje ręcznie bibliotek celem jakichś testów, to używam DOWN.

Jednym słowem usuwam kontener, i tworze go znowu.

 

Co gdy nie można usunąć obrazów i kontenerów?

Zdarza się, że w testach tak zamieszamy :) przy tworzeniu multum wersji, zmian itp (standard), że nie można wygenerować nic nowego, lub nie widać zmian.

Wtedy tutaj przychodzą do pomocy polecenia dockerowe.

Zatrzymywanie wszystkich kontenerów dockerowych

Usuwanie wszystkich kontenerów, również które są ukryte na pierwszy rzut oka

Usuwanie wszystkich obrazów dockerowych na serwerze (ściągnięte, lub wygenerowane przez nas)

Usuwanie reszty obrazów,  jeśli nie usuneło wszystkiego a jest na liście docker images

Zdarza się, że nie można usunąć obrazów, ponieważ pojawia się błąd:

Error response from daemon: conflict: unable to delete ba62b42dad38 (cannot be forced) – image has dependent child images

Musimy wtedy skorzystać z flagi Force. (mówimy oczywiście o serwerze developerskim, gdzie możemy wszystko usuwać i niczego się nie obawiać, że stracimy dane :) )

Sprawdzamy czy usuneliśmy wszystko możemy poleceniami

 

Aliasy – czyli jak ułatwić sobie pracę

Sam korzystam z aliasów, które można znaleźć tutaj https://github.com/tcnksm/docker-alias/blob/master/zshrc

Krótkie wyjaśnienie: https://kartar.net/2014/03/useful-docker-bash-functions-and-aliases/

Jednym słowem, używam głównie poleceń:

dstop – zatrzymanie WSZYSTKICH kontenerów

drm – usunięcie wszystkich kontenerów

dri – usunięcie wszystkich obrazów

dalias – spis wszystkich aliasów dockerowych

dex nazwa-kontenera bash – wejście w dany kontener

 

I to tyle :) 

Mogłem dać spis poleceń na usuwanie pojedynczych obrazów lub kontenerów, ale o tym wszędzie piszą :) więc na pewno umiesz to robić, lub znajdziesz rozwiązanie.

Na lokalnym komputerze, korzystam z wszystkich poleceń, usuwam wszystko itp. Na serwerach w internecie, trzeba wsiąść pod uwagę, że możesz posiadać limit transferu. Więc każdorazowe usuwanie obrazów, i zaciąganie ich, spowoduje jego zużywanie. Ja wtedy usuwam, konkretny obraz (jeśli trzeba)

W razie pytań, lub moich błędów, pisz !

 

 

[MyFood] Docker – api, web, loadbalancing, ssl (darmowy),mysql – pełny config

Nadszedł czas wdrożenia środowiska developerskiego, oraz środowiska produkcyjnego. Od początku moim planem było wykorzystanie dockera. Dzięki niemu łatwo wszystko postawić na nowym serwerze. Najtrudniejsze jak zwykle było stworzenie pierwszy raz kompleksowej konfiguracji, z wszystkimi elementami, które są potrzebne w każdym projekcie.

Co to docker przeczytać możesz tutaj: 1, 23

Spis wszystkich kontenerów

  • serwer api
  • serwer api2 (drugi serwer do testu loadbalancingu – normalnie w swoim projekcie nie używam, dlatego jest to kopiuj / wklej api)
  • serwer web
  • baza danych (mysql)
  • phpmyadmin (tylko dla dev)
  • haproxy
  • letsencrypt (odnawiany 90 dniowy certyfikat SSL)

Dlaczego tyle kontenerów i w czym problem

Zasadą w świecie dockera jest „1 kontener = 1 zadanie” . A więc nie powinno w jednym kontenerze instalować się kilku funkcjonalności: serwer www, skrypty (np php), baza danych. Bardzo ciężko pilnować gdy coś się popsuje , oraz ciężko wgrać aktualizacje do systemu. Dlatego wszystko wydzielamy do kontenerów, która lista jest powyżej.

Problem:

Nie można do kilku kontenerów przydzielić tego samego portu.

Czyli nie można jak niżej:

  • web – nasłuchuje na porcie 80
  • api – nasłuchuje na porcie 80

Przy próbie odpalenia pojawi się błąd:

Co oznacza tyle że port już jest używany i nie można odpalić kontenera. Jest to oczywiście logiczne, bo jak wchodzimy np na localhost, to system by nie wiedział na który kontener przekierować ruch.

Kolejny problem to domeny. Konfiguracja dockera nie używa takiego pojęcia jak domena / subdomena. Każdy kontener sam powinien rozpoznawać domenę, i serwować odpowiednie dane.

W konfiguracji dockera nie możemy podzielić ruchu dla danej domeny i dla danego portu.

Jak to zrobić?

Musimy sami to obsłużyć prz pomocy serwera proxy. Użytkownik wchodzi na stronę w danej domenie, to serwer proxy wyświetla mu dane z odpowiedniego kontenera dockera.

Serwer proxy rozpoznaje domene, oraz port, i odpowiednio serwuje dane.

Rozwiązań jest kilka, np:

  • na serwerze (host) instalujemy proxy i w konfiguracji ustawiamy i przekierowujemy domenę na dany kontener (1)
  • wykorzystujemy tylko kontenery dockerowe, i serwer proxy również jest w nim (2)

Wybieram rozwiązanie 2. – dobrze jest mieć porządek :)

Serwer Proxy – HAProxy – Load Balancing – SSL

Postawienie proxy, pozwala nam zainstalować również certyfikaty SSL, i je odpowiednio skonfigurować. Nie trzeba tego robić w każdym kontenerze. Wystarczy w jednym :)

Wykorzystamy tutaj certyfikaty „Let’s encrypt” https://letsencrypt.org/ – pozwala nam to za DARMO posiadać na swojej domenie ssl.

Certyfikat jest ważny 90 dni. Całe generowanie i pobieranie jest automatyczne, więc nie musimy się o to martwić.  PEŁNA AUTOMATYKA !

Serwer proxy również umożliwia wykorzystanie loadbalancingu. Co to jest? Jeśli ustawimy dla danego adresu np: https://api.myfood.love/ dwa kontenery. To proxy dzieli ruch po połowie i wysyła go to kontenera. Jak wejdziesz na testowy serwer api to po odświeżeniu strony będą się na przemiennie pojawiać informacje:

Ip:xxx.xxx.xxx.xxx Host: 8ca086de8527

oraz

Ip: xxx.xxx.xxx.xxx Host: cccc89c4b35c

Dla przykładu wyświetlam ip oraz host. Host się zmienia w zależności od wybranego kontenera.

Po co load balancing?

Jeśli strona posiada duży ruch i maszyna nie wytrzymuje, to można dodać kolejną maszynę i obsłużyć dwa razy większy ruch. Klient nawet nie zauważy że ruch idzie z dwóch maszyn.

Konfiguracja środowiska – docker-compose.yml

Wszystkie obrazy jakie wykorzystuje znajdują się w pliku docker-compose.yml. Dzięki temu wystarczy odpalić jedno polecenie (docker-compose up -d) i dzieje się magia.

Oddzielnie stworze post z poleceniami, trickami itp, więc tutaj tylko suche fakty na temat pliku konfiguracyjnego :)

Aktualnie cały plik konfiguracyjny jest w wersji „3.1”. Oznacz to, że wersja dockera jaka powinna być to min. 1.13, a wersja docker-compose 1.11

Pełny plik konfiguracyjny (api z load balancingiem)

Pełne wyjaśnienie – hierarchia plików i katalogów https://github.com/mfratczak/myfood-generator

api.myfood.love – load balancing z api i api2

  • build – budowanie kontenera gdzie plik Dockerfile znajduje się w podkatalogu
    • context: Docker/python – katalog kontenera (Docker/python)
    • dockerfile: Dockerfile – nazwa pliku z konfiguracją kontenera, można np zmienic na Dockerfile-dev i będą ustawienia developerskie (jeśli taki plik istnieje)
  • environment: – zmienne systemowe przekazywane do środka kontenera
    • FORCE_SSL=yes – zmienna wykorzystywana w kontenerze haproxy – bardzo ważna zmienna dla haproxy i certyfikatu SSL
    • VIRTUAL_HOST=xxx – spis hostów które kierować mają na dany kontener, można podać kilka  – bardzo ważna zmienna dla haproxy i certyfikatu SSL
  • volumes: – mapowanie katalogów, aby projekt znajdował się poza kontenerem. Dzięki temu można usunąć całkowicie kontenery i utworzyć jeszcze raz a dane zostają
    • ./WebServer:/app – w katalogu WebServer znajduje się cały projekt systemu Api
  • links: – połączenie między kontenerami, kontener API ma dostęp do kontenera MYSQŁ, gdzie znajduje się baza danych
  • command: python server.py – możliwość zadeklarowania polecenia z jakim ma się uruchomić kontener, tutaj odpala serwer pythona, można dla wersji developerskiej zrobić np: python server-dev.py, czyli odpalić serwer pythona z ustawieniami pełnego logowania itp
  • restart: always – deklaracja co ma się stać jak kontener padnie, lub polecenie (python server.py) spowoduje błąd, czyli szybki restart maszyny
  • network_mode: „bridge” – wybór podsieci

Drobne wyjaśnienie odnośnie network_mode. Normalnie wszystkie kontenery z danego katalogu (z jednego pliku dockerfile) znajdują się w osobnej podsieci. Okazuje się, że serwer proxy działa tylko w głównej podsieci o nazwie „bridge”, dlatego wszystkie kontenery są dodane do niej.

Drugie drobne wyjaśnienie to FORCE_SSL. Dla testów lokalnych linijkę tą mam wyłączoną, ponieważ dla lokalnych domen (localhost, itp) nie można utworzyć certyfikatu

Ustawienie: VIRTUAL_HOST w api i w api2 na te same domeny powoduje, że proxy stosuje load balancing i dzieli ruch między te dwa kontenery.

myfood.love – serwer web

W pliku konfiguracyjnym powyżej, tworzę również serwer pythona do testów. Jednak różnicą jest zmiana w VIRTUAL_HOST, co powoduje, że ruch tutaj jest obsługiwany tylko przez jeden kontener.

W przyszłości tutaj będzie zmiana pliku konfiguracyjnego na ten z katalogu Docker/npm/Dockerfile (teraz jest tylko szybka kopia aby sprawdzić działanie haproxy)

– mysql oraz phpmyadmin

  • image: sameersbn/mysql:latest – popularny gotowy obraz mysql (posiadają również postgresql itp)
  • volumes: – ./Data/database:/var/lib/mysql – cała baza została wydzielona do podkatalogu database. Dzięki temu można wyłaczać i włączać kontener bazodanowy bez utraty danych
  • environment – zmienne z danymi do utworzenia pustej bazy

oraz

  • image: phpmyadmin/phpmyadmin – gotowy obraz z phpmyadminem
  • ports: – „9999:80” – kontener dostępny np pod localhost:9999 lokalnie, lub myfood.love:9999 w sieci, w wersji produkcyjnej dostęp do phpmyadmina powinien być WYŁĄCZONY!!!
  • environment: PMA_HOST: mysql – zmienna wskazuje na kontener w której jest baza

Małe wyjaśnienie: Przy tworzeniu bazy (pierwsze odpalenie kontenera mysql) dane są zapisane w katalogu Data/database. Tworzona jest czysta baza o podanej nazwie, loginie i haśle. Restart / Wyłączenie / Usunięcie i ponowne utworzenie kontenera nie powoduje utraty danych bazy. Aby usunąć dane, należy opróżnić katalog. Po opróżnieniu katalogu, ponowne uruchomienie kontenera bazodanowego powoduje utworzenie czystej bazy.

– letsencrypt

  • image: interaction/letsencrypt:master – gotowy obraz
  • environment:
    • DOMAINS=api.myfood.love myfood.love – domeny które powinny mieć ssl, dla nich jest generowany certyfikat, nie mogą to być domeny lokalne lub zmapowane w pliku host systemu
    • [email protected] – email który jest zawarty w certyfikacie, powinien to być istniejący adres email
  • expose: – „80” – port na którym nasłuchuje kontener
  • volumes:
    • ./Data/letsencrypt:/etc/letsencrypt – zmapowany katalog z wygenerowanymi certyfikatami
    • ./Logs/letsencrypt:/var/log/letsencrypt – zmapowany katalog gdzie można przejrzeć logi

– haproxy – serwer proxy przez który przechodzi cały ruch z portu 80 i 443 (każda domena i subdomena)

  • image: interaction/haproxy:master
  • links: – kontener musi być podłączony do letsencrypt oraz do wszystkich kontenerów na który ma być kierowany ruch
  • depends_on: – polecenie to sprawia, że haproxy odpalane jest na końcu, oraz że zależy jego działanie od innych kontenerów
  • ports: – „80:80” – „443:443” – cały ruch przechodzi przez ten kontener, potrzebne są do obsługi dwa porty 80 (zwykły ruch http) oraz 443 (ruch https)
  • volumes: – ./Data/letsencrypt:/etc/letsencrypt – haproxy oraz letsencrypt muszą dzielić ten sam katalog, z wygenerowanymi certyfikatami

Kilka spraw:

Ważną kwestią aby haproxy działał z SSL, to współdzielenie katalogu letsencrypt. Kontener letsencrypt przy odpaleniu oraz co 24h sprawdza certyfikat i generuje nową wersje. Gdy haproxy wykryje że pliki w katalogu się zmieniły, uaktualnia certyfikaty u siebie. Nigdy więc nie wygaśnie certyfikat SSL ponieważ jest on generowany co 24h

Dodatkowo można wydzielić haproxy razem z letsencrypt z pliku konfiguracyjnego dockerfile, i utworzyć 2 kontenery globalne.

Dzięki temu, w przyszłości można utworzyć całkiem nowe domeny, z nowymi kontenerami, i dodać ich obsługę w haproxy. Ale przykład podam następnym razem.

Koniec

Jeśli dotarłeś do końca, to podziwiam, i dziękuję. Jeśli uważasz, że można to rozpisać łatwiej, zostaw komentarz, na pewno zaktualizuje w przyszłości tą rozpiskę.

 

Ważne linki:

  • https://github.com/docker/dockercloud-haproxy – czysty haproxy bez SSL (przykład docker-compose >>)
  • https://github.com/ixc/letsencrypt-dockercloud-haproxy – użyty obraz haproxy z SSL ‚let’s encrypt
  • https://letsencrypt.org/ – darmowy certyfikat SSL
  • https://docs.docker.com/compose/compose-file/#dockerfile – opis dockerfile u źródeł

 

[03 MyFood] Stworzenie szablonu HTML

Od czego zacząć jak niczego nie ma

Wpis powiązany z projektem MyFood. Szczegóły tutaj »
  • Stworzenie repozytorium [zrobione] – https://github.com/mfratczak/myfood-generator
  • Stworzenie szablonu szablonu html [w trakcie]
  • Wgranie aktualnej wersji projektu na domenę [wymyślam nazwę domeny, masz propozycje? pisz!]

Github

Przy tworzeniu nowego repozytorium, github automatyzuje tworzenie pliku z licencją (wybrałem licencje MIT). Drugą rzeczą ułatwiającą życie jest utworzenie automatycznie pliku .gitignore na podstawie wybranej technologii projektu. Co daje ten plik?

Git sprawdza plik .gitignore, i przy kolejnym pushu, ignoruje pliki nie powiązane z projektem, lub pliki które są generowane automatycznie (cache, kompilacje itp).

Dzięki temu nie wysyłamy do repo zbędnych plików, oraz trzymamy porządek.

Czytaj więcej

[01 MyFood] Geneza projektu, i jego cele

Start Projektu MyFood Generator

Jeśli śledzisz mojego bloga, to wiesz, że startuje w konkursie „Daj się poznać” edycja 2017. Dla tego konkursu wybrałem projekt „MyFood Generator” czyli w skrócie „Generator posiłków”.

Projekt będzie dostępny pod domeną: http://myfood.love

Geneza projektu

Walczę aktualnie z nietolerancją pokarmową, i co miesiąc dostaje pełny jadłospis dla dwóch osób, na 30 dni. Każdy posiłek może posiadać 2 warianty [dla każdej osoby inne ilości].

Przygotowanie listy dań, listy zakupów, oraz następnie gotowanie (5 posiłków) zabiera mnóstwo czasu :) . Samego gotowania nie można usprawnić programistycznie, można za to usprawnić przygotowanie posiłków :).

Cel

  • wrzucenie wszystkich posiłków do systemu (śniadanie, 2 śniadanie, obiad, kolacja, podwieczorek)
    • możliwość przypisania posiłku do diety, grupy, tag’a
  • stworzenie jadłospisu dla x dni, z istniejących dań w systemie
    • użytkownik sam wybiera listę dań
    • użytkownikowi losuje jadłospis (wg kryteriów, wszystkie w systemie)
  • dla każdego jadłospisu stworzenie możliwości generowania listy zakupów
    • pełna lista zakupów dla wybranych dań, lub wybranych dni
    • możliwość zmiany listy zakupów (np posiadamy marchewkę w lodówce, to nie chcemy aby ona była na liście zakupów)
    • generowanie plików w różnych formatach (pdf, txt), możliwość wysłania listy na email
  • wyszukiwarka
    • możliwość wyszukania dania po wybranych składnikach (np. mamy w lodówce 5 składników, i chcemy znaleźć dostępne dania)
    • szukanie po nazwie
    • szukanie po czasie przygotowania posiłku
    • szukanie po rodzaju posiłku
  • opcje socialmedia: dzielenie się posiłkami z innymi użytkownikami systemu, lub udostępnianie postów na fb (itp)
  • kalendarz / pamiętnik posiłków – oznaczanie posiłku (zjedzony, nie zjedzony, itp), możliwosć dodania opisu do dania, zdjęcia, czasu wykonania
  • statystyki i raporty [czas wykonywania posiłku, zjedzone posiłki w miesiącu, zjedzone kalorie, itp]
  • możliwośc wydruku przepisu, jadłospisu, listy zakupów
  • inne (np podpięcie toggl time tracker do mierzenia czasu wykonywania posiłków, …)

Technologie wykorzystywane w projekcie

Na codzień pracuje z PHP i w nim tworze strony i systemy IT. Postanowiłem więc rozpocząć projekt w którym wszystkiego musze nauczyć się prawie od początku :) a więc:

  • backend: python 3(framework flask) w którym napisane będzie api
  • frontend: react (framework js)
  • docker – do odpalenia projektu w izolowanym wirtualnym środowisku, używając jednego polecenia
  • szablon strony napisany przy wykorzystaniu semantic-ui.com (Semantic UI to zestaw komponentów wspomagający tworzenie interfejsu użytkownika)
  • baza danych mysql
  • testy automatyczne
  • zewnętrzna baza składników (? opcja) – użytkownik wpisuje marchewka do dania, i jak jej nie znajduje to pobiera dane z zewn systemu (kalorie, itp)
  • … (wyjdzie w praniu)

Dlaczego python api? Chciałbym w przyszłości stworzyć aplikacje na komórki. Istniejące API pozwoli zrobić to niższym kosztem :) . W czym to napisze, jeszcze nie wiem. Wstępnie będzie to w Electronie -> https://electron.atom.io/

Posty związane z projektem

W regulaminu konkursu, musza pojawiać się dwa posty tygodniowo z tagiem DSP2017

  • minimum raz na tydzień pojawiać się będzie post dotyczący projektu #MyFood
  • drugi post może być powiązany z projektem, ale nie musi

Moim planem jest rozpisanie krok po kroku tworzenia projektu.  Nie będą to jednak szczegółowe posty typu: to skopiuj, tu wklej, tu zrób to i to. Wpisy mają cię nakierować na rozwiązanie istniejącego problemu, rozpisanie działania, linków do bazy wiedzy / tutoriali z których skorzystałem. Przykładowe problemy:

  • postawienie dockera, posiadające skonfigurowane biblioteki python, mysql (itp)
  • stworzenie środowiska dla semantic-ui do stworzenia szablonu projektu (gulp, npm, less)
  • stworzenie testów automatycznych (jestem całkowicie zielony w tym :(  )

I to tyle na starcie :) , sporo pracy przedemną. Nie wiem czy uda mi się skończyć projekt do końca konkursu. Celem jest stworzenie kompleksowo napisanego kodu, którym będę mógł się pochwalić bez wstydu :) . Przy okazji osoby będą mogli skorzystać z postów i wykorzystać części rozwiązań w swoich projektach.


Repozytorium git: https://github.com/mfratczak/myfood-generator – tutaj możesz obejrzeć kody źródłowe, i odpalić projekt na swoim serwerze.

Google Analytics Alternative