FAQ
I've tried some of the options:

    1. Deploying using git. (git repo on the server with git init --bare and
    placing a hook to build and copy files)
    2. Deploying using "Capistrano" - Seems more like a standard.
    3. Deploying using some configuration management system like puppet or
    chef .. Build a package (rpm or deb), and update it via the CMS.

But is there a "Go" method that's being used and that I'm missing out ?
Or is it like - "It's a language. You find your own way to mess around your
infrastructure" ?

Problems I face:
1. Go is not installed on all servers where the application will be
deployed. So compilation on all servers is a bad idea
2. Development System architecture and flavor is different from deploy
system architecture and flavor. Would you recommend go-cross-compile for
production use ?
3. It's not going to be a single file. Say it's a webapp, then there are
configuration files, static files, templates, etc.. which needs to be
bundled together too, and all these make things complicated.

Need some help finding a work-around for solving these issues.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Rodrigo Kochenburger at Sep 25, 2013 at 8:10 pm
    Go compiles to a single binary so IMO the best way is to take advantage of
    that.

    Compile (or cross compile) your app, on your deploy you simple copy the
    binary to your servers and restart. Of course, some basic infrastructure
    around it so you can do zero down time restarts and be able to rollback is
    also recommended.

    This is specially good cause you can build once and deploy many times, so
    you don't duplicate work in all servers.

    - RK

    On Wed, Sep 25, 2013 at 12:43 PM, Boopathi Rajaa wrote:

    I've tried some of the options:

    1. Deploying using git. (git repo on the server with git init --bare
    and placing a hook to build and copy files)
    2. Deploying using "Capistrano" - Seems more like a standard.
    3. Deploying using some configuration management system like puppet or
    chef .. Build a package (rpm or deb), and update it via the CMS.

    But is there a "Go" method that's being used and that I'm missing out ?
    Or is it like - "It's a language. You find your own way to mess around
    your infrastructure" ?

    Problems I face:
    1. Go is not installed on all servers where the application will be
    deployed. So compilation on all servers is a bad idea
    2. Development System architecture and flavor is different from deploy
    system architecture and flavor. Would you recommend go-cross-compile for
    production use ?
    3. It's not going to be a single file. Say it's a webapp, then there are
    configuration files, static files, templates, etc.. which needs to be
    bundled together too, and all these make things complicated.

    Need some help finding a work-around for solving these issues.

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rodrigo Kochenburger at Sep 25, 2013 at 8:11 pm
    I missed your 3rd item. There are tools that can bundle together the assets
    but you can always create a distribution package (.tgz) with the
    pre-compiled binary and assets.

    - RK

    On Wed, Sep 25, 2013 at 1:10 PM, Rodrigo Kochenburger wrote:

    Go compiles to a single binary so IMO the best way is to take advantage of
    that.

    Compile (or cross compile) your app, on your deploy you simple copy the
    binary to your servers and restart. Of course, some basic infrastructure
    around it so you can do zero down time restarts and be able to rollback is
    also recommended.

    This is specially good cause you can build once and deploy many times, so
    you don't duplicate work in all servers.

    - RK

    On Wed, Sep 25, 2013 at 12:43 PM, Boopathi Rajaa wrote:

    I've tried some of the options:

    1. Deploying using git. (git repo on the server with git init --bare
    and placing a hook to build and copy files)
    2. Deploying using "Capistrano" - Seems more like a standard.
    3. Deploying using some configuration management system like puppet
    or chef .. Build a package (rpm or deb), and update it via the CMS.

    But is there a "Go" method that's being used and that I'm missing out ?
    Or is it like - "It's a language. You find your own way to mess around
    your infrastructure" ?

    Problems I face:
    1. Go is not installed on all servers where the application will be
    deployed. So compilation on all servers is a bad idea
    2. Development System architecture and flavor is different from deploy
    system architecture and flavor. Would you recommend go-cross-compile for
    production use ?
    3. It's not going to be a single file. Say it's a webapp, then there are
    configuration files, static files, templates, etc.. which needs to be
    bundled together too, and all these make things complicated.

    Need some help finding a work-around for solving these issues.

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Robert Melton at Sep 25, 2013 at 8:22 pm
    Hi!

    Deploying Go is IMHO, one of my favorite parts of Go. It is drop-dead
    simple and pairs well with almost any tooling you can imagine, choose
    your favorite!

    On Wed, Sep 25, 2013 at 3:43 PM, Boopathi Rajaa wrote:
    Problems I face:
    1. Go is not installed on all servers where the application will be
    deployed. So compilation on all servers is a bad idea
    Why should production servers have code anyway, ick!

    2. Development System architecture and flavor is different from deploy
    system architecture and flavor. Would you recommend go-cross-compile for
    production use ?
    Absolutely. If you are using straight Go, the cross compile features
    work amazingly well and are really, really simple to setup. If you
    have come from cross-compilation in other languages, don't be scared
    -- this "just works"(tm). I have a few line bash file that works for
    setting up cross-compliation on linux and os-x, but a better resources
    is Dave Cheney's blog posts as well as links to more information,
    start here: http://dave.cheney.net/2013/07/09/an-introduction-to-cross-compilation-with-go-1-1

    3. It's not going to be a single file. Say it's a webapp, then there are
    configuration files, static files, templates, etc.. which needs to be
    bundled together too, and all these make things complicated.
    There are a ton of tools to bundle up all your webapp resources into
    your binary. You can decide for yourself how valuable these are to
    you. We ended up with shipping a zip file that is read at startup
    rather than jamming those resources into our binary, seemed cleaner to
    us. Removed a bit of the sex-appeal of explaining you only ship one
    binary and nothing else. We looked at
    https://github.com/jessevdk/go-assets and
    https://github.com/carbocation/gotogether when considering embedding.

    --
    Robert Melton

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Benjamin Measures at Sep 25, 2013 at 8:57 pm

    On Wednesday, 25 September 2013 20:43:28 UTC+1, Boopathi Rajaa wrote:

    I've tried some of the options:

    1. Deploying using git. (git repo on the server with git init --bare
    and placing a hook to build and copy files)
    2. Deploying using "Capistrano" - Seems more like a standard.
    3. Deploying using some configuration management system like puppet or
    chef .. Build a package (rpm or deb), and update it via the CMS.

    But is there a "Go" method that's being used and that I'm missing out ?
    Personally, I'd just "go get" from a production repo.

    However, since:

    Problems I face:
    1. Go is not installed on all servers where the application will be
    deployed. So compilation on all servers is a bad idea
    If you have a Perl application you need Perl installed, a Java app Java
    installed and so on. Why not go?

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rodrigo Kochenburger at Sep 25, 2013 at 9:08 pm

    If you have a Perl application you need Perl installed, a Java app Java
    installed and so on. Why not go?
    Because go does not run in a interpreter neither in a VM. It's like
    requiring everyone to have a C compiler to be able to run any C written app
    :)

    Being able to build once and run everywhere is the reason behind the
    statically linked binary.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Benjamin Measures at Sep 25, 2013 at 9:39 pm

    On Wednesday, 25 September 2013 22:08:35 UTC+1, Rodrigo Kochenburger wrote:

    If you have a Perl application you need Perl installed, a Java app Java
    installed and so on. Why not go?
    Because go does not run in a interpreter neither in a VM. It's like
    requiring everyone to have a C compiler to be able to run any C written app
    :)
    Perhaps the short question was phrased badly: it wasn't suggesting Go is
    *required* to run a Go binary, just asking what the problem is with having
    it installed.

    The common objections are:
    1. Security;
    2. Space; and
    3. "but it's a development tool"

    Being able to build once and run everywhere is the reason behind the
    statically linked binary.
    No, it's not and it can't - for example
    http://code.google.com/p/go/issues/detail?id=3780.

    The reason is due to the linkers only being capable of static
    linking: http://golang.org/doc/faq#Why_is_my_trivial_program_such_a_large_binary
    . If you do a quick search on opinions of the Go creators on dynamic
    linking however, you'll soon find the real reason is that it was a choice
    based on the rejection of the traditionally-claimed benefits of dynamic
    linking.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Robert Melton at Sep 25, 2013 at 9:56 pm

    On Wed, Sep 25, 2013 at 5:39 PM, Benjamin Measures wrote:
    Being able to build once and run everywhere is the reason behind the
    statically linked binary.

    No, it's not and it can't - for example
    http://code.google.com/p/go/issues/detail?id=3780.
    Correct, but the cross-complication features make it really trivial to
    for example, do dev on OS-X and build/deploy on Linux.

    --
    Robert Melton

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rodrigo Kochenburger at Sep 25, 2013 at 10:39 pm

    Being able to build once and run everywhere is the reason behind the
    statically linked binary.
    No, it's not and it can't - for example
    http://code.google.com/p/go/issues/detail?id=3780.

    The reason is due to the linkers only being capable of static linking:
    http://golang.org/doc/faq#Why_is_my_trivial_program_such_a_large_binary. If you do a quick search on opinions of the Go creators on dynamic
    linking however, you'll soon find the real reason is that it was a choice
    based on the rejection of the traditionally-claimed benefits of dynamic
    linking.
    That issue is a portability issue. For each support architecture/os, the
    runtime/stdlib expects certain syscall and options to be available and some
    older linux versions are not available. It has *nothing* to do w/ the
    static/dynamic linking decision.

    The linkers are part of the go tool and the decision behind implementing
    the linkers with no support for dynamic links is exactly to have
    self-contained executables. Of course, because it compiles to machine code
    the binary is not portable but that's why the tool was also built w/ easy
    cross compilation.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Robert Melton at Sep 25, 2013 at 9:22 pm

    On Wed, Sep 25, 2013 at 4:57 PM, Benjamin Measures wrote:
    If you have a Perl application you need Perl installed, a Java app Java
    installed and so on. Why not go?
    Because not having to have a runtime on the platform is one of the
    major advantages of Go? Why have a full compiler (which you need to
    keep up to date and manage) on every single server you have? Why have
    your source code on every server you have? Why have your git
    credentials on every server you deploy to... that is the path to
    insanity.

    Go IMPROVED on Java, Perl, etc by removing this dependency and
    allowing you to deploy static binaries... I am already used to it and
    never want to go back!

    --
    Robert Melton

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Paulo Pinto at Sep 26, 2013 at 2:32 pm

    Am Mittwoch, 25. September 2013 23:21:55 UTC+2 schrieb Robert Melton:
    On Wed, Sep 25, 2013 at 4:57 PM, Benjamin Measures
    <saint....@gmail.com <javascript:>> wrote:
    If you have a Perl application you need Perl installed, a Java app Java
    installed and so on. Why not go?
    Because not having to have a runtime on the platform is one of the
    major advantages of Go? Why have a full compiler (which you need to
    keep up to date and manage) on every single server you have? Why have
    your source code on every server you have? Why have your git
    credentials on every server you deploy to... that is the path to
    insanity.

    Go IMPROVED on Java, Perl, etc by removing this dependency and
    allowing you to deploy static binaries... I am already used to it and
    never want to go back!

    --
    Robert Melton

    Well, Go brought back what was already possible before the industry went
    crazy with VMs.

    The possibility to use strong typed languages with native code compilers.

    --
    Paulo

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Boopathi Rajaa at Oct 1, 2013 at 11:16 am
    Personally, I'd just "go get" from a production repo.
    I would like to extend my question here.
    Not about `go get` on production server, But about go get in a production
    application.

    I feel it's not safe to `go get` a random guy's github repository when
    compiling for a production level application ?

    Should I maintain a separate clone of the stable version of that repository
    that I forked and used, and consequently maintain it's HEAD ?
    Or
    Should I maintain a test program that'd test the functions I'd be needing
    from the repository ?

    Which, in your opinion, do you think is a better way to do it ?

    I assume that `go get` has not yet implemented getting something other than
    the HEAD.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dick Davies at Oct 1, 2013 at 6:42 pm
    I can't see there being much overhead* to maintaining a local mirror of
    remote
    repos and 'go get'ting that. You're also able to deploy when github is down
    that way :)

    * : compared to maintaining whatever the Go equivalent of Gemfile /
    project.clj / pom.xml would
           be.

    Interested to hear counterarguments obviously - I just tried goxc and
    that's a very strong
    deployment story, so I'm planning to be shipping Go into prod before too
    long.


    On 1 October 2013 12:16, Boopathi Rajaa wrote:


    I feel it's not safe to `go get` a random guy's github repository when
    compiling for a production level application ?

    Should I maintain a separate clone of the stable version of that
    repository that I forked and used, and consequently maintain it's HEAD ?
    Or
    Should I maintain a test program that'd test the functions I'd be needing
    from the repository ?
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • RickyS at Sep 26, 2013 at 3:32 am
    No matter what, you still have to run staging and testing on the same
    architecture and OS version as production.
    And the OS must be at the same patch level.
    If you are deploying to more than one OS then you need to test on all of
    those OSs.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Robert Melton at Sep 26, 2013 at 3:55 am

    On Wed, Sep 25, 2013 at 11:32 PM, RickyS wrote:
    No matter what, you still have to run staging and testing on the same
    architecture and OS version as production.
    And the OS must be at the same patch level.
    If you are deploying to more than one OS then you need to test on all of
    those OSs.
    Wait, why? If I am developing pure Go on Ubuntu/amd64 13.04 Desktop
    and my deployment is to CentOS/amd64 EL 6.4. Why do I care about the
    patch level on the OS? As long as it shares the same architecture,
    and am I not doing system interactions, why do I care? I fear I might
    have misunderstood the way static builds and Go work (going to read
    up).

    --
    Robert Melton

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Tamás Gulácsi at Sep 26, 2013 at 6:56 am
    libc

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jijesh Mohan at Sep 26, 2013 at 2:32 pm
    The cross compilation worked very well for me. My development machine is
    Mac and I have deployed the app in Openshift by pushing the linux amd64
    architecture build from the dev box. Go doesn't required any dependencies (
    not using any C library bindings) is the best thing for deployment.



    On Thu, Sep 26, 2013 at 12:26 PM, Tamás Gulácsi wrote:

    libc

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Benjamin Measures at Sep 27, 2013 at 9:11 pm

    On Thursday, 26 September 2013 10:54:50 UTC+1, Jijesh Mohan wrote:

    Go doesn't required any dependencies ( not using any C library bindings)
    is the best thing for deployment.
    C programs can be statically linked [1]. So can Perl applications [2].
    Contrary to popular opinion, in many cases Go will actually produce a
    dynamically linked binary [3].

    That your binaries are probably not dependency free aside, deploying a
    single binary is nice when you're in control of deployments, though it
    doesn't really work when you need to redistribute binaries to end-users
    where the packages/libraries you depend on have incompatible licences.

    Static vs dynamic linking is an age-old argument, and you should probably
    make yourself aware of the pros and cons of each rather than follow blind
    fanaticism.

    [1] http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
    [2] http://search.cpan.org/~mlehmann/App-Staticperl-1.43/bin/staticperl
    [3]
    $ echo > four-oh-four.go <<EOF
    package main

    import (
             "net/http"
    )

    func main() {
             http.ListenAndServe(":8080", http.NotFoundHandler())
    }
    EOF
    $ go build four-oh-four.go
    $ ldd four-oh-four
             linux-vdso.so.1 (0x00007fff4a1f1000)
             libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fa9d28fe000)
             libc.so.6 => /usr/lib/libc.so.6 (0x00007fa9d2553000)
             /lib64/ld-linux-x86-64.so.2 (0x00007fa9d2b1c000)

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rodrigo Kochenburger at Sep 27, 2013 at 9:14 pm

    $ echo > four-oh-four.go <<EOF
    package main

    import (
    "net/http"
    )

    func main() {
    http.ListenAndServe(":8080", http.NotFoundHandler())
    }
    EOF
    $ go build four-oh-four.go
    $ ldd four-oh-four
    linux-vdso.so.1 (0x00007fff4a1f1000)
    libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fa9d28fe000)
    libc.so.6 => /usr/lib/libc.so.6 (0x00007fa9d2553000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fa9d2b1c000)
    FYI, in that case you can easily achieve static linking by doing
    CGO_ENABLED="0" on <=1.1.2 or by using -tags netgo on >=1.2

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Benjamin Measures at Sep 27, 2013 at 10:08 pm

    On Friday, 27 September 2013 22:14:06 UTC+1, Rodrigo Kochenburger wrote:
    FYI, in that case you can easily achieve static linking by doing
    CGO_ENABLED="0" on <=1.1.2 or by using -tags netgo on >=1.2
    It doesn't quite do the same thing. For instance, if this is enabled the
    binary will need to be restarted to pick up changes to resolv.conf .

    Bringing it back on point, FYI you can easily achieve static linking for
    gcc by using -static . There are reasons though why this hasn't taken off
    (and these apply regardless of language).

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rodrigo Kochenburger at Sep 27, 2013 at 10:24 pm

    FYI, in that case you can easily achieve static linking by doing
    CGO_ENABLED="0" on <=1.1.2 or by using -tags netgo on >=1.2
    It doesn't quite do the same thing. For instance, if this is enabled the
    binary will need to be restarted to pick up changes to resolv.conf .

    Bringing it back on point, FYI you can easily achieve static linking for
    gcc by using -static . There are reasons though why this hasn't taken off
    (and these apply regardless of language).
    Yes, you're right about the resolv.conf part but it will eventually be
    fixed: http://tip.golang.org/src/pkg/net/dnsclient_unix.go#L11

    I was just showing *how* one can produce a fully static linked binary to
    take advantage of the benefits of it, which I beg to say are many.
    Specially if you need to deploy your binary in multiple machines, or is
    running your application in any public/private cloud platform.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedSep 25, '13 at 7:43p
activeOct 1, '13 at 6:42p
posts21
users9
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase