Komentáře k článku

„Prostě to tam nahrajte FTPčkem“ – nebo ne?

Nahrání skriptů na server (angl. deploy, česky „nasazení“) mnozí považují za věc, u které není moc co řešit. Co taky řešit u něčeho tak triviálního, jako je upload skriptů, že? Pojďme se podívat na některé věci, které s nahráváním skriptů souvisí, a ukažme si, jak je řešit pomocí verzovacího systému.

Zpět na článek

39 komentářů k článku „Prostě to tam nahrajte FTPčkem“ – nebo ne?:

  1. Kepi

    SSH přístup a deploy

    My například na ruby-hosting.cz poskytujeme SSH přístup už pár let a deploy Ruby on Rails aplikací přes capistrano nabízíme od začátku.

    U PHP hostingů máme SSH pravda jen pro několik VIP zákazníků a sami to vnímáme jako nedostatek, ale už se na tom pracuje. Každopádně těžko říct, jak nabídnout nějaké standardizované řešení pro deploy na PHP a hlavně bude o něj zájem?

    Osobně mám (možná zbytečný) strach, že o takové služby zájem není a i když příjdeme s něčím novým, zůstane to nepovšimnuto. Možná je to jen špatnou propagací, kdoví…

    1. Martin MalýAutor příspěvku

      Re: SSH přístup a deploy

      To je začarovaný kruh – „takové služby neposkytujeme, protože o ně není zájem“ x „takové služby nebudeme používat, protože je v ČR nikdo nenabízí“. Totéž jako se známým „kruhovým důkazem“ Internet Exploreru.

      U Ruby, Javy a dalších existují standardizované nástroje, takže nikoho nepřekvapí, že ruby hosting něco takového nabízí. Jde spíš o ty desítky, snad i stovky LAMP hostingů…

      Zájem o ně bude úměrný tomu, jak je budete propagovat. Pokud to nenabídnete, tak se po tom nikdo ptát nebude a ti, co to budou potřebovat, použijí služeb jiného poskytovatele. Takže dokud to nenabídnete, tak bude zájem nulový. Pokud přijdete s něčím novým, zkuste o tom informovat – pošlete nám mail, že něco nového máte, nebo přidejte zprávičku.

      1. Tomas

        Re: SSH přístup a deploy

        Na co tuto sluzbu? Od roku 2000 co delam webove stranky jsem nepocitil potrebu neceho takoveho.

        1. Tomas

          Re: SSH přístup a deploy

          Jeste me napada jedna vec jak jste psal o tom multihostingu. Je Vam doufam znamo ze pokud v zahranici vyuzivate tuto sluzbu treba u hostmonsteru ze neni neomezena a pri prvnim problemu se zatezi Vas suspenduji a vsechny weby si muzete strcit…. A neni to jen hostmonster.

          Techto zahranicnich poskytovatelu je velka spousta. Viz. Site5, ktery tu predstavoval pan Krcmar jako to nej nej a po precteni pravidel bych si tam nenechal ani hnusne MFA. Cesky clovicek by nejradsi to nej nej a pokud mozno zadarmo. Jenze tohle takto nefunguje nenacpete na jeden ucet 100 domen za 10$ mesicne!!!

          1. Martin MalýAutor příspěvku

            Re: SSH přístup a deploy

            Nikdo netvrdí, že nacpe sto domén na účet za USD10. Českému človíčkovi jen vrtá hlavou, proč za mnohem víc peněz dostává mnohem horší nabídku služeb, a proč některé služby nesežene ve stejné kategorii vůbec.

        2. Martin MalýAutor příspěvku

          Re: SSH přístup a deploy

          Tak to je ideální příležitost dát tomu šanci. Přečtěte si třeba ten seriál o Gitu, možná vás překvapí, jak technologie za těch deset let pokročila, a možná zjistíte, oč pohodlnější práce s tím je.

    2. janvlcek

      Re: SSH přístup a deploy

      Už nějakou dobu pro deployment PHP aplikace nad Zendem používáme Capistrano. Inspirovali jsme se projektem Capifony (Capistrano pro symfony – https://github.com/everzet/capifony). Je závislost na Ruby moc velkou překážkou pro standardizaci deploymentu PHP projektů?

      1. patrik.sima

        Re: SSH přístup a deploy

        Dlouho používám git-ftp.py v pythonu a ničemu to nevadí. Ovšem pracuji na linuxu, kde jsou tyto nástroje běžně dostupné. Ve Windows je třeba Python doinstalovat. Mimochodem Capistrano doporučuje přímo Github na http://help.github.com/capistrano/

        1. Michal

          Re: SSH přístup a deploy

          Problem je, ze ceske hostingy vetsinou ssh neposkytuji a kdyz ano, tak pouze na SCP/rsync…. :-/

  2. smilelover

    SCP pres Ant

    Vetsinu webu mam na Klenot.cz a tam pouzivam SCP pres Ant. http://ant.apache.org/manual/Tasks/scp.html

    Nahraji se jen zmenene soubory a s Antem umi dnes pracovat vetsina IDEcek, takze deploy je otazkou treba jedne klavesove zkratky…

    Uz me ale taky napadl nejaky system, ktery by vyuzival VCS. Kazdopadne bych to resil pres nejaky tag, protoze temer nikdy nechce clovek deployovat vse, co je v repozitari.

    1. Martin MalýAutor příspěvku

      Re: SCP pres Ant

      Určitě tagovat změny k nahrání, nebo je přidávat do nějaké „deploy“ větve… VCS mají v tomto mnoho možností, je na každém, jak si práci zorganizuje.

  3. K-Kamil

    Další protokoly

    FTP je hrozný protokol (zabezpečení, propustnost přes firewally a další). Je zajímavé, že pro publikování směrem na server se moc neujal WebDAV. Ten se přitom používá vnitřně v některých komerčních produktech.

    1. Jerry12

      Re: Další protokoly

      Pevne doufam, ze uz dneska vetsina lidi vi, ze SSL/TLS nejsou na ozbodu a pouziva SFTP nebo SCP misto klasickyho FTPcka.

  4. salko

    RSync

    My už nejakú dobu používame na deploy rsync. Dávnejšie, ešte keď sme mali SVN, tak sme sa snažili robiť deploy pomocou SVN hook skriptov, ale bolo to ťažkopádne.

  5. Petr

    Re: "Prostě to tam nahrajte FTPčkem" - nebo ne?

    Mercurial používám, ale na deploy na Live by mě to asi nenapadlo, přijde mi to náchylné k chybám. Musím udržovat tagy, musím mít hosting co to bude umět (který u nás?), musím.. Nakonec něco špatně otaguji nebo udělám jinou drobnost a problém. Já to pomocí Mercurialu dávám na svůj lokální server, tam to otestuji a když jsem spokojen, zabalím změněné soubory a na webu udělám „rozbal a přepiš“. Mám tak nějak pocit, že nad tím mám větší kontrolu, mám tam ponechaný i předchozí balík, takže kdyby něco, mohu honem udělat rozbal a přepiš s tím starším a jsem zpět (pokud se neměnila struktura db). Jasně, Mercurial mi taky umožňuje vracet, ale tohle je určitě rychlejší způsob návratu a prakticky v něm nejde udělat chyba.

  6. dasim

    Re: "Prostě to tam nahrajte FTPčkem" - nebo ne?

    Už několik měsíců používám Git a co mi nějvíc usnadnilo život je Beanstalk. Vedle privátních repozitářů, spolupráce apod. je jeho killer-feature jednoduchý deployment.

    Dokáže provést deploy přes FTP automaticky při každém commitu, na základě „značky“ v commit message nebo jen kliknutím na tlačítko. Navíc se k deploy dají jednoduše přidat pre- a post-hooky v podobě nějakých HTTP požadavků.

    Určitě existují stejné nebo lepší řešení, které i budou zadarmo, ale pokud někdo nění tak zběhlý v podobných věcech (jako já) a za těch $15/měsíc už mi to ušetřilo času i starostí dost a dost. Místo FTP klienta a pátrání ve složkách kam nahrát pár změněných souborů otevřu konzoli git, commit, push a hotovo.

  7. Tomáš Bláha

    diff/patch

    Zajímavé téma. Já sice přímo nějaký VCS na deployment nepoužívám, ale vždy mám ve zvyku si vytvořit mezi vývojovou a nasazenou verzí diff, projít ho a zkontrolovat, a potom teprve aplikovat příkazem patch.

    A doslova rostu, pokud mám někde na cizím serveru „jen“ ftp. Už jsem zažil i takové, kde se soubor par desítek KB nahrával půl minuty a mezitím samozřejmě upload nebyl atomický, takže server házel syntaktické chyby na postupně se zvyšujícím číslu řádku. Stále tedy nechápu, jak to ti lidé, kteří považují FTP za „přece standard“, dělají.

  8. v6ak

    Maintenance a AJAX

    Co nemusí na první pohled někomu dojít, je, že maintenance s AJAXem je celkem komplikace. Pokud místo několika obrázků nabídnete jen maintenance, obrázky se nezobrazí a po reloadu se uživatel dozví příčinu. U AJAXu je situace složitější: Kromě toho, že není možné jako u obrázků prostě to směřovat na starší verzi, následky maintenance HTML mohou být horší:
    * Pokud není správně zpracován chybný stav XHR, může dojít ke ztrátě dat z formuláře, mystifikaci uživatele („Odesláno.“) apod.
    * I pokud je, nemusí dát srozumitelnou zprávu na špatný JSON nebo podobně.

  9. Michal Holub

    Capistrano web interface

    Ještě bych mohl doporučit webistrano – grafický frontend nad capistrano – tohle + GIT je bomba, takže i méně zdatní developeři (ti co nemusí command line) zvládají deploy.

  10. edois

    aptitude

    Ja to resim tak, ze mam vse v debianich balickach, mam vlastni debian repository a kdyz chci neco nasadit, tak to ubalim, nahraju do repa a na serveru/serverech (vetsinou mi to bezi 2x kvuli redundanci) udelam aptitude update && aptitude install balicek :)

      1. Martin MalýAutor příspěvku

        Re: aptitude

        Zvažoval jsem ji, nakonec jsem zahrnul do možnosti „Jiný inteligentní způsob“ :)

    1. František Kučera

      Re: aptitude

      jj, to je skvělý přístup.

      Akorát je trochu nevýhoda, že ten kdo nasazuje, musí být root – zatímco když se nasazuje přes SFTP (SSH) nebo verzovací systém, může to dělat i někdo jiný (tzn. vývojář/admin aplikace nemusí být správce serveru).

      Nebo používáš automatické updaty a instaluje se každá nová verze? To by asi bylo řešení.

      1. edois

        Re: aptitude

        Vzhledem k tomu, ze na ty stroje stejne muzou jen admini, nam to nevadi. Naopak je fajn, ze tam vyvojari nemuzou nahravat, co se jim zlibi, takze mame dobry prehled co se kde deje…

    2. koubel

      Re: aptitude

      ano, balíčky bych bral i jako lepší způsob než vcs. Když už někdo nechce dělat distribuční balíčky, tak v PHP existuje už léta PEAR s celou infrastrukturou ohledně balíčků.
      Nově v PHP 5.3 dokonce phar – http://cz.php.net/manual/en/book.phar.php, pomocí něhož uděláte obdobu toho, co je v Javě war.

      1. v6ak

        Re: RSYNC

        Zkoušel jsem jen fuse FTP (konkrétně curlftpfs a gvfs FTP). Nevím, čím to bylo, ale měl jsem to značně nestabilní. Pro čtení to někdy použitelné bylo, ale jakmile jsem se snažil zapsat, obvykle se to nezapsalo a nastal I/O hang. Snad má někdo lepší zkušenosti. S oběma nástroji mám podobné zkušenosti.

  11. Martin

    PHP deployment

    Zdravim, nasa mala firma pouziva na PHP cesky hosting. Zda sa mi že jedine čo použiva česky hosting je FTP pristup. Vedel by mi niekto odporučit aké z spomínaných riešení be bolo pre nás a hlavne pre mna najlepsie… To ftp je fakt na nervy, kedze prave vyuzivame casto CMS a upload je zdlhavy a hlavne pri malych upravach tento pristup deploymentu neskutocne zdrzuje … Dik

    1. Tharos

      Re: PHP deployment

      Zdravím Martine, občas si taky u nějakého projektu musím vystačit s FTP a vyvinul jsem si následující „nouzové“ řešení. Používám v něm TortoiseSVN (takže SVN, ale stejně by to šlo například i s Gitem) a WebDrive (existují myslím i volně dostupné alternativy).

      1. Vzdálený prostor si připojím přes WebDrive jako diskovou jednotku.

      2. V ní si založím v rootu složku například „_repo“, ve kterém přes TortoiseSVN vytvořím SVN úložiště. Přes .htaccess zakáži do této složky HTTP přístup.

      3. Ve vzdáleném prostoru vytvořím přímo v rootu přes TortoiseSVN jednu pracovní kopii, která bude představovat produkční verzi.

      4. Vedle složky „_repo“ si v rootu vytvořím ještě například složku „_stage“, uvnitř které vytvořím další pracovní kopii. To bude testovací verze na produkčním serveru. U té přes .htaccess zaktivuji HTTP autentizaci.

      5. A na závěr si i u sebe na lokálním serveru vytvořím pracovní kopii, ve které bude probíhat vývoj.

      Workflow je následující: vývoj probíhá na lokálním serveru v lokální pracovní kopii. Když dojde na deployment, jednoduše provedu commit změn (do úložiště připojeného přes WebDrive) a ve vzdáleném prostoru provedu SVN update stage pracovní kopie. Vše otestuji na doméně http://nejakadomena.tld/_stage a když to funguje, provedu jen SVN update produkční pracovní kopie.

      Co se týče databáze, i když je k dispozici jednom jedna, lze s pomocí prefixů tabulek provozovat zároveň produkční i testovací verzi.

      Tohle je metoda, která s pouhým FTP přístupem dokáže přinést veškerý komfort pokročilejšího deploymentu. Tak snad někomu dobře poslouží. :)

      1. Petr

        Re: PHP deployment

        pokusil jsem se vytvořit úložiště na FTP, ale ať dělám co dělám, tak nejde vytvořit na FTP úložiště… Jak nastavit práva adresáře ve kterém to chci vytvořit? nejde to ani když dám práva 777.

  12. Almad

    Rollback?

    Jsem jediny, kdo nahrava tarball do verzovaneho adresare, pak symlinkne a az kdyz se to skontroluje, tak smaze celou verzi?

    A jsem jediny, kdo provadi nejake operace mezi tim co se vezme z devel repa a co se nasazuje? (.mo, minifikace, anyone?)

  13. Tomáš

    PHP hostingy s APC a jiné

    přinejmenčím APC opcode cache, umožnujě funkci která říká že při změně kódu(datum změny) php souborů se ještě X sekund používá zkompilovaná verze starého kódu.
    .htaccess toto možná dokáže ovlivnit.
    Za předpokladu že dnešní webhostingy toto mají, dá se tím částečně omezit dopak metody zmíněné v článku. (či při rozbal+přepiš, trvajícím nějaké ty sekundy)

    1. Michal Wiglasz

      Re: PHP hostingy s APC a jiné

      Ale zase se na to dojde z druhé strany. Po uplynutí X sekund se část souborů už překompiluje, ale u části se ještě bude používat stará verze (než jim uplyne těch X sekund).

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3401