Integration Testing
Integration testing is about taking the units of code developed with unit testing and combine them together into the desired system. It (can) also mean testing software by including dependencies such as database, screen, communication, micro-services, etc. This is as opposed to unit testing something and mocking and stubbing out all the dependencies (basically you assume they work and provide the values you expect in the test).
Sometimes integration testing can be divided into 'local' and 'full'. Local means test the code along with all the other code that it works with for that application (but not outside apps and dependencies). Full means testing the full application with all the code and all the dependencies and services.
Continuous Integration Testing
Continuous Integration Testing is about a development workflow. It means having a remote server running a program such as Jenkins, CircleCI, etc. so that you commit code and test locally first (maybe just run a few unit tests) and then you push the committed code changes (usually in a branch) to the remote server which runs all the tests in the test suite(s), possibly using parallelization for efficiency of time. When changes are merged into master you also push master to the CI server to run the full test suite before deploying the code into production.
I would be amiss if I didn't also mention:
Continuous Delivery
This is a system (actually employed by some large players in the field - yahoo, etc.) to have a 'pipeline' whereby changes by a developer are made and then there are a series of sets of automated tests that will run, each set being triggered by the success of the previous set. If all the sets pass the changes will actually be deployed to production. I've seen this done with 50 changes a day.