Webhosting s ssl + git + npm + gulp + bower rubrika: Administrace: Hardware

1 mawebis
položil/-a 21.8.2015
 
upravil/-a 21.8.2015

Hezký den všem,

už nějakou dobu koukám kam se přesunout se svými prezentacemi a protože jsem se poslední dobou zhýčkal gulp + bower, tak bych toto od hostingu také vyžadoval. Nechce se mi jít do něčeho co bych musel sám spravovat (žádné VPS), spíše by se mi líbilo:

==== Určitě chci ====

deploy skrze git

npm + gulp + bower

ssl přístup

sftp či fpts

php 5.6.x

sqlite3

rozumný prostor na disku (min 3GB)

neomezený počet domén namířený na tento hosting

možnost nastavit si čas na běh php scriptu aspoň na 30 vteřin

Composer

dobrá konektivita z Česka

==== Nepotřebuji ====

mail schránka

databáze (kromě sqlite3)

škálovatelné na vysokou zátěž (jedná se o stránky s 50ti přístupy denně)

Existuje prosím něco takového a nebo budu muset zatnout zuby a jít do VPS?

Díky moc,
Petr

Komentáře

  • Kit : 30 sekund je málo, méně než 1 minuta nebývá. 21.8.2015
  • mawebis : Ok, to je možné. Ale když se nevejdu do 30ti vteřin tak dělám něco zle : ) Plus když bude více, tak je to příjemný bonus. 30, bylo limit. 21.8.2015
  • bazo : preco potrebujes spustat gulp bower a npm na serveri? lepsie je si to zbuildit lokalne ako pri kazdom deployi cakat strasne dlho kym to vsetko dobehne 21.8.2015
  • kohven : Existuje hezké pravidlo, že nic, co se generuje, by nemělo být v repozitáři. A docela s ním souhlasím. 21.8.2015
  • mawebis : hm, chtěl bych mít takovéto workflow deploy aplikace: 1) "Vyvíjím lokálně" - tady mám vskutku rozběhané gulp+npm+bower 2) na GitHub posílám jen zdrojové kódy a nic co mi generuje task menager + mít třeba ve svém projektu na githubu stažené i jquery a další nepovažuji zcela čisté - nejsou to moje kódy, dají se dotáhnout dynamicky, správně na můj repozitář nepatří 3) Na hostingu bych toto dotahoval právě po deploy nové verze. Deploy na produkci nepředpokládám častěji nežli 1x týdně, myslím že to server takovoudle zátěž zvládne 21.8.2015
  • bazo : ja s vami suhlasim, ale ked sa ti kvoli zmene jedneho riadku v php pri deployi budu 5min generovat assety asi velmi nadseny nebudes :) tiez som si to zazil, ale deploy robim castejsie, obcas aj parkrat za sebou 21.8.2015
  • mawebis : doufám, že mě vícenásobný deploy čekat nebude : ) ale jinak souhlasím, že občas se může vyplatit posílat již předpřipravené balíčky. 21.8.2015
  • v6ak : Build lokálně ještě neznamená, že musejí být 3rd party věci v repozitáři. Pokud deploy nebude probíhat přes verzovací systém, tak nemusí. 23.8.2015
  • v6ak : BTW, nechtěl bych SSL, ale TLS. 23.8.2015
  • TomMarius : Pokud s tim par (maximalne 2) mesicu pockas, presne takovy hosting ve firme pripravujeme. Mohl bys mi prosim napsat na mail mariustom(at)email.cz (osobni)? - moc rad bych ti ukazal par screenshotu naseho admin CP a zeptal se te na nazor, protoze jsi presne model naseho zakaznika. 29.8.2015
  • mawebis : Hezký den, děkuji za informaci, zaslal jsem Vám e-mail. Děkuji za informaci. 31.8.2015
odkaz
9 arron
odpověděl/-a 23.8.2015

Tvůj problém není v hledání hostinu, Tvůj problém je ve špatném deploy workflow. Čas, který věnuješ hledání hostinu lépe využij k tomu, aby ses naučil deploy dělat lépe :-) Chápu, že na stránkách, kde máš takovouhle návštěvnost Tě to moc netrápí, ale stejné to není dobrý důvod, proč ten deploy dělat špatně (a obzvlášť, když Ti to zjevně přidělává práci hledáním hostingu). Použij buď nějaký nástroj na vytvoření "buildu" anebo si napiš jednoduchý skript, který do nového adresáře udělá clone repozitáře a spustí všechny programy nutné pro získání závislostí. Pak už můžeš provést běžnou synchronizaci přes ftp (nebo tam ty zdrojáky na server dostat jakoukoliv další cestou).

Tvůj problém s hostingem přestane v tu chvíli existovat, bude Ti vyhovovat prakticky cokoliv :-) A ještě to budeš dělat lépe, než to děláš teď :-)

Komentáře

  • Michal Kleiner : Souhlasim s arronem, jedna vec je hosting, druha vec je build proces. Doporucil bych se podivat treba na https://codeship.com/, ale jsou i dalsi alternativy, pokud chces treba lokalni build a mit CI/CD server pod kontrolou, ve virtualu se da rozjet https://github.com/Strider-CD/strider. 24.8.2015
  • Občan : Lze rozvést proč je @mawebis deploy "špatný" a verze, která je lepší? Také používám deploy přes TSL+GIT a posílám pouze zdrojáky. A jsem docela rád, že klasický FTP potkám, tak jednou za rok. 24.8.2015
  • mawebis : Osobně jsem se snažil udělat workflow na deploy co nejednodušší co mě napadlo, plus dokázal bych si to bez problémů i nascriptovat. Ve firmě používám Bamboo na tyto věci, ale na soukro projekt (minimalistického rozsahu) mi to připadalo jako jít kanónem na vrabce. Plus, říkal jsem si že je rok 2015, takže hostingové firmy po tom co se naučili konečně ssl, tak bych od nich neočekával zamrznutí, ale další rozvoj pro vývojáře. Ale bohužel i dle toho, že mi tu zatím nikdo nenapsal "Jo to je jasné v Česku tohle nabízí tyhle tři firmy", tak jsem se asi zmýlil : ( 24.8.2015
  • arron : Vyjděme z toho, co tady už bylo řečeno a to, že "do repozitáře zdrojové kódy závislostí nepatří". Pak tam ale nepatří ani třeba transpilovaný JS, CSS a další věci. Patří tam jenom výchozí zdroje. A to se ještě dnesk běžně dělá i další kompilace/minimalizace/concatifiace (heh, nový slovo :-D) a co já vím, co ještě. Takže na serveru by se pak musely nejenom stahovat závislosti, ale i provádět celý "build" těhle věcí okolo. Když pominu, že je staha udělat deploy co nejrychleji (v řádu vteřin) a tenhle proces může trvat mnoho minut, tak co se stane, když se vyskytne nějaká chyba? Deploy se nezdaří a aplikace bude nedostupná než dojde k opravě? To může trvat i další destíky minut nebo třeba i hodiny...Takže si celý "build" (stažení závislostí, transpilace/kompilace/whatever, spuštění testů atd.) připravíme raději někde bokem (pomocí skriptu, nějakého build nástroje, to je fuk) a pokud všechno proběhlo v pořádku, tak můžeme udělat balíček určený na deploy. Může to být prostý zip, může to být rpm nebo cokoliv, co potřebujeme. Na serveru se pak zdrojáky jenom nahrají (ideálně někam bokem a pak se změní symlink) a je ve své podstatě hotovo (ještě se musí smazat cache, když je potřeba a další věci podle aplikace, ale tohle je takový to gro). Takže asi tak :-) Snad jsem odpověděl @Občanovi :-) 24.8.2015
  • arron : @mawebis: Víš co, pokud si seš vědom všech nedostatků, tak ten Tvůj způsob může být v pořádku, ale ten hosting tady nejspíš takhle nebude, protože to tímhle způsobem lidé prostě nedělají :-) 24.8.2015
  • v6ak : @arron: Jo, mám takové zkušenosti… Build probíhá na serveru, zatímco běží stará verze. Problém je v tom, že pro ten build je někdy málo RAM. Na druhou stranu, pokud build probíhá u vývojáře, mohou nastat různé problémy s prostředím. Například jsem si nainstalovat Javu 8, na serveru měl Javu 7 a neměl v projektu nastavenou targetVersion, takže se to zkompilovalo pro Javu 8 a na serveru se to s Javou 7 nespustilo. (To je řešitelné, ale dá se na něco zapomenout…) Navíc mhže mezi více vývojáři vzniknout trošku race condition, pokud dva chtějí deployovat současně. Pro větší projekty bude asi nejlepší mít oddělený build server. Ono všechno má svoje pro a proti, ale build na produkčním serveru bych spíše nedělal. 24.8.2015
  • Občan : Ano, do repozitáře závislosti nepatří, to je zákon. Add co se stane, když něco selže: Deploy na serveru je sekvence akcí a poslední je teprve live. Když jedna selže na localu vypíše git fail a nic závažnýho se něděje a live krok se neprovede. Dokonce se provedou případně i testy před live. (Osobně testuju jenom zda je OK konfigurace, cca 10 řádků), o hodiny nejde, naopak deploy provádím klávesovou zkratkou a jistí vše revert. Build sice probíhá nějakou tu dekádu vteřin, ovšem zda musí proběhnout na localu, nebo na serveru neovlivní rychost, kdy bude verze live. 24.8.2015
  • mawebis : Koukám, že se diskuze začíná stáčet dost k deploy workflow : ) Z praktického hlediska bych se případné havárie nebál, měl bych na serveru prostě dva adresáře - jeden v němž by se připravovala nová verze a druhá s živým webem a po úspěšném a zkontrolovaném buildu bych jen přejmenoval složky -> otázka pár mikrosekund. Žádný dlouhý výpadek by neměl nastat. Jsem založením pro minimalistické řešení. Jestli, ale @arron znáš nějaké opravdu jednoduchý deploy nástroj, jen že vyrovná jednoduchému skritpu + práci s gitem tak se rád nechám rád poučit. Ale opravdu se jedná o minimalistický projekt. Děkuji moc. 24.8.2015

Pro zobrazení všech 3 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.