At the very start he compiled a binary on his [OSX?] machine. Then he SSH's into a box on gcloud that is a Ubuntu machine and he runs the binary. I understand how to compile go for linux targets but how the heck was the binary "already there" on his linux box???
I've never used to Go but it looks like he targeted his Go build for a Linux machine just to show us how that part is done. Then he went into his remote machine that already had the same application built and ready to go. It's like those cooking shows where they make a dish in front of the audience then put it into the oven then immediately pull out the completed dish that was made earlier.
Derek Anderson - thanks. Totally understand how to cross compile go. I just could not wrap my head around how did the binary magically already be inside the Linux box he SSHed after he built the binary. I think the cooking show analogy above nailed it.
In Go compiler, you just tell which system you target. All runtimes are there out of the box. The default is the system you run so my mac builds Darwin, but the only thing you need to do to build Linux binary instead is pass env variable GOOS=linux. Similarly, you could pass GOARCH=386 for example. Number systems supported out if the box is really impressive. Additionally, you can use special code comments to compile a different file(s) based on the target system or use naming conventions. main.go would compile your system main_linux.go to Linux, go_windows.go to Windows and so on without any additional work.
You can map a folder on a remote machine using things like Samba and I recently noted even simpler things that will share a folder in two places--I think with SSH. It's certainly possible that he glossed over a file transfer, but I know people will often tinker on a Raspberry Pi in this way. Personally, if I deploy to Linux, I also compile in Docker, but that's not what happened here.
This is quite an interesting thing to play around with, but would you ever really have your Go application deploy itself? Usually this kind of thing would be handled by something else anyway that automates these same tasks. That in itself seems more advantageous because why should your Go binary even know about Kubernetes. It's fun to see, but I think quite impractical. A good demo for Kubernetes and Google's Cloud Platform however.
Agree 100 % - separation of concerns. What if the Kubernetes library baked into your binary targets older version of the Kubernetes API that your cluster is running in? Why would you waste RAM and disk space by embedding deployment tools inside your programs.. Cool demo, but far from practical.
Where is the code for this demo?
At the very start he compiled a binary on his [OSX?] machine. Then he SSH's into a box on gcloud that is a Ubuntu machine and he runs the binary. I understand how to compile go for linux targets but how the heck was the binary "already there" on his linux box???
I've never used to Go but it looks like he targeted his Go build for a Linux machine just to show us how that part is done. Then he went into his remote machine that already had the same application built and ready to go. It's like those cooking shows where they make a dish in front of the audience then put it into the oven then immediately pull out the completed dish that was made earlier.
The GOOS=linux environment variable tells go to build for linux, regardless of what kind of machine you are building on.
Derek Anderson - thanks. Totally understand how to cross compile go. I just could not wrap my head around how did the binary magically already be inside the Linux box he SSHed after he built the binary. I think the cooking show analogy above nailed it.
In Go compiler, you just tell which system you target. All runtimes are there out of the box. The default is the system you run so my mac builds Darwin, but the only thing you need to do to build Linux binary instead is pass env variable GOOS=linux. Similarly, you could pass GOARCH=386 for example. Number systems supported out if the box is really impressive. Additionally, you can use special code comments to compile a different file(s) based on the target system or use naming conventions. main.go would compile your system main_linux.go to Linux, go_windows.go to Windows and so on without any additional work.
You can map a folder on a remote machine using things like Samba and I recently noted even simpler things that will share a folder in two places--I think with SSH. It's certainly possible that he glossed over a file transfer, but I know people will often tinker on a Raspberry Pi in this way. Personally, if I deploy to Linux, I also compile in Docker, but that's not what happened here.
This is quite an interesting thing to play around with, but would you ever really have your Go application deploy itself? Usually this kind of thing would be handled by something else anyway that automates these same tasks. That in itself seems more advantageous because why should your Go binary even know about Kubernetes. It's fun to see, but I think quite impractical. A good demo for Kubernetes and Google's Cloud Platform however.
Agree 100 % - separation of concerns. What if the Kubernetes library baked into your binary targets older version of the Kubernetes API that your cluster is running in? Why would you waste RAM and disk space by embedding deployment tools inside your programs.. Cool demo, but far from practical.
Excellent talk!